Почему ssh обеспечивает небезопасную пересылку вне хоста?

В вызове переадресации локального порта ниже,

[me@TunnelBeginHost]$ ssh -L TunnelBeginPort:TunnelEndHost:TunnelEndPort ViaUser@ViaHost

Учитывая тот факт, что часть туннеля между ViaHostи TunnelEndHostявляется небезопасной, склонной к прослушиванию сети и тому sshподобное , почему даже предоставляется такая опция? Безопасность sshдолжна быть в центре , если бы она не требовала аутентификации и в TunnelEndHost ... скажем, с (гипотетическим) синтаксисом, например,

[me@TunnelBeginHost]$ # Proposed syntax:
[me@TunnelBeginHost]$ ssh -L TunnelBeginPort:TunnelEndUser:TunnelEndHost:TunnelEndPort ViaUser@ViaHost

что бы обеспечить безопасный туннель между ViaHostи TunnelEndHostтак же?

Аналогично, для удаленной переадресации портов.

Понимание логического обоснования этой возможности sshпоможет прояснить любые заблуждения, которые могут возникнуть у меня по поводу sshтуннелирования, или о предостережениях безопасности, связанных с ним.

ssh security port-forwarding

— Гарри
источник

Ответы:

Во-первых, « часть туннеля между ViaHost и TunnelEndHost небезопасна » - это не факт . Вы предполагаете, что конечный хост будет подключен через общедоступный Интернет, но это не всегда так - я мог бы использовать туннель для HTTPS, это могло бы быть через IPsec, зашифрованный VPN или просто физически защищенное кабельное соединение. Локальная сеть моей виртуальной машины не подвержена прослушиванию, пока я единственный, у кого есть root на моем ноутбуке.

Во-вторых, что сказал @Xeross - как бы вы проходили аутентификацию в предложенной вами схеме? Используя какой протокол? Функция туннеля была создана для поддержки произвольных TCP-соединений. Что если конечный хост не поддерживает SSH, TLS или ваш любимый протокол? Если вы решили требовать поддержку SSH на конечном хосте, тогда вся функция туннеля становится практически бесполезной, поскольку пользователь может просто подключить SSH к конечному хосту напрямую.

Наконец, почему бы и нет? sshне может знать условия сети пользователя лучше, чем сам пользователь (как видно из первого абзаца), и добавление произвольных ограничений, таких как это, может просто помешать их работе. sshздесь, чтобы помочь, но не для няни, как это принято в программах Unix.

— grawity
источник

Я предполагаю, что (1) сетевой трафик в / из TunnelEndHostможет быть перехвачен, даже если он находится в обычной интрасети без IPsec; (2) TunnelEndHostимеет sshdработу, и что команда в синтаксисе предложенного выше потерпит неудачу , если нет. Разве не правда, что (небезопасные) TCP-туннели также могут быть созданы с помощью такой программы socat, так почему же нужно sshдобровольно предлагать небезопасные функции, как это?

— Гарри

«... вся функция туннеля становится практически бесполезной, так как пользователь может напрямую подключиться к конечному хосту только по SSH». Не уверен, что я следую за тобой. Клиент и сервер, которые подключаются через этот туннель, могут быть небезопасными, поэтому наличие sshконечной точки все равно поможет.

— Гарри

@Harry: « Я предполагаю, что ... » Вы снова принимаете произвольные условия, и эти предположения ложны для очень многих случаев использования.

— Гравитация

Как именно будет работать аутентификация конечной точки, учитывая, что конечной точкой может быть что угодно, HTTP, HTTPS и т. Д. (Вы поняли).

Если трафик должен быть зашифрован, то любой протокол, который вы пытаетесь отправить через туннель, должен сам позаботиться об этом.

— Нет в наличии
источник

Аутентификация конечной точки будет работать так же, как и для нее ViaUser@ViaHost, только если она запросит 2 пароля: один для аутентификации ViaUser@ViaHost(и он уже делает это в настоящее время), а другой для аутентификации TunnelEndUser@TunnelEndHost.

— Гарри

@Harry: Что если ты туннелируешь что-то кроме SSH ?

— grawity

@grawity Почему вы спрашиваете об этом только в случае пересылки вне хоста?

— Гарри

@ Гарри, потому что это тот случай, когда вы не можете пройти аутентификацию с SSH в месте назначения, потому что место назначения не SSH

— Недоступно

«потому что пункт назначения не SSH». В этом случае SSH не должен предлагать построить туннель до пункта назначения. Я предполагаю, что это был весь смысл моего первоначального вопроса; а именно: если SSH не может обеспечить безопасный сквозной туннель, то он не должен пытаться предоставить частично защищенный и частично незащищенный. OTOH, он может попытаться предоставить безопасный сквозной туннель с дополнительной аутентификацией SSH для конечной точки туннеля. Небезопасные туннели, которые всегда можно построить socat.

— Гарри

-2

Переадресация вне хоста является частично защищенной и небезопасной функцией ssh, что делает ее в целом небезопасной .

manСтраница ssh сусла включать явное предостережение относительно этого. К сожалению, это не так, как в версии openssh-clients-5.8p2-25.fc16.i686.

— Гарри
источник