[Comm] Работа по протоколу ssh через proxy-сервер, corkscrew

[Sergey Vlasov]

On Sat, Feb 09, 2008 at 02:35:22PM +0500, kaf на nevod.ru wrote:
> Но если с компьютера в школе имеется только одна дырка в Inet через
> HTTP-прокси-сервер.
> Как я понял в этом случае я могу возпользоваться тем же механизмом, но
> прописав в качестве транспорта в настройках ssh программу corkscrew.

Возможный вариант (другой способ - применение transconnect; эта
программа через LD_PRELOAD подменяет функции libc, работающие с
сокетами, на свои реализации, работающие через метод CONNECT).

> Она используя метод CONNECT proxy-сервера может обеспечить доступ с
> компьютера в локальной сети proxy-сервера о протоколу ssh на внешний
> компьютер.
> Одна из проблем там описана - возможно малый TTL на CONNECT, но по-моему
> эта проблема решаема...

Для ssh можно использовать опцию ServerAliveInterval в ~/.ssh/config,
чтобы обеспечить поддержание соединения.

> Вопроса собственно два - работал ли кто с данным механизмом (corkscrew
> судя по всему активно портируется в рамках sisyphus). Универсален ни он
> - позволяет ли он проходит ЛЮБЫЕ прокси-сервера.

Проблем с использованием метода CONNECT несколько:

1. Список портов, с которыми можно устанавливать соединения, как
   правило, ограничен (например, в стандартных настройках squid
   соединения с портом 22, используемым sshd, запрещены).  Нужно либо
   договариваться с администратором прокси об открытии нужных портов,
   либо (при отсутствии возможности повлиять на настройки прокси)
   вешать sshd на один из разрешённых портов (например, на порт 443 -
   https, для которого в первую очередь и предназначался метод
   CONNECT).

2. Прокси может проверить, что соединение, установленное через метод
   CONNECT, действительно использует протокол SSL/TLS (хотя сами
   данные защищены средствами TLS, можно проверить наличие заголовков
   TLS, процесс согласования протоколов шифрования, ...); в этом
   случае проброс других протоколов (например, SSH) работать не будет.
   Правда, squid таких проверок не делает.  В случае, если попался
   такой прокси, придётся ставить на наружный сервер stunnel, чтобы
   прокси видел протокол SSL, используемый stunnel.

3. Вроде бы существуют даже такие прокси, которые при использовании
   TLS выполняют "атаку man-in-the-middle", чтобы добраться до
   зашифрованных данных (например, с целью проверки на вирусы).
   Конечно, подобное безобразие видимо для клиента (вместо сертификата
   сервера он будет видеть сертификат прокси, а результаты проверки
   сертификата сервера до него вообще не дойдут).  Через такой прокси
   вообще ничего не пролезет, кроме настоящего HTTP[S].

> И позволяет ли он делать обратный проброс из внешней сети во внутреннюю? 

Можно реализовать такой проброс средствами ssh (например,
RemoteForward со стороны клиента; при необходимости разрешить
GatewayPorts в настройках sshd).
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/community/attachments/20080209/b9aa33aa/attachment-0002.bin>