Почему слушатель обратного SSH-прокси доступен только на сервере
Проверьте адрес привязки удалённого слушателя и режим GatewayPorts, прежде чем менять протокол прокси или учётные данные.
Удалённая переадресация может работать с SSH-сервера, но отклонять подключения с другой машины, потому что слушает только на loopback. Сначала проверьте фактический адрес прослушивания.
На стороне сервера GatewayPorts | Привязка удалённой переадресации |
|---|---|
no, по умолчанию | Ограничивает слушателей loopback |
yes | Принудительно привязывает ко всем адресам (wildcard) |
clientspecified | Позволяет клиенту запросить конкретный адрес привязки |
Для слушателя, предназначенного для одного контролируемого интерфейса, сервер может использовать:
GatewayPorts clientspecifiedЗатем клиент запрашивает подходящий адрес в своей спецификации -R. Этот адрес должен существовать на удалённой машине, а другие ограничения переадресации по-прежнему действуют. Клиентский -g не является взаимозаменяемым управлением для этого направления.
Три разрешения остаются раздельными: авторизация SSH на создание переадресации, сетевой доступ к её слушателю и собственная политика доступа службы HTTP или SOCKS. Вход по SSH аутентифицирует создателя туннеля; он не аутентифицирует каждого последующего вызывающего общий слушатель и не добавляет запрос пароля SOCKS.
Если удалённый вызывающий по-прежнему не может подключиться, проверьте в этом порядке адрес привязки, ограничения переадресации сервера и путь через межсетевой экран. После того как TCP достигнет слушателя, неудачное рукопожатие прокси — это более поздняя проблема.