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