Pse një dëgjues i proxy SSH të kundërt arrihet vetëm në server
Kontrolloni adresën e bind të dëgjuesit në distancë dhe modalitetin GatewayPorts përpara se të ndryshoni protokollin e proxy-t ose kredencialet.
Një përcjellje në distancë mund të funksionojë nga serveri SSH, por të refuzojë lidhjet nga një makinë tjetër sepse dëgjon vetëm në loopback. Kontrolloni së pari adresën e vërtetë të dëgjimit.
Në anën e serverit GatewayPorts | Bind-i i përcjelljes në distancë |
|---|---|
no, parazgjedhja | Kufizon dëgjuesit në loopback |
yes | Detyron bind wildcard |
clientspecified | Lejon klientin të kërkojë një adresë bind të caktuar |
Për një dëgjues të destinuar për një ndërfaqe të kontrolluar, serveri mund të përdorë:
GatewayPorts clientspecifiedKlienti më pas kërkon një adresë të përshtatshme në specifikimin e tij -R. Kjo adresë duhet të ekzistojë në makinën në distancë, dhe kufizimet e tjera të përcjelljes vazhdojnë të zbatohen. -g në anën e klientit nuk është kontroll i këmbyeshëm për këtë drejtim.
Tre leje mbeten të ndara: autorizimi SSH për të krijuar përcjelljen, aksesi në rrjet ndaj dëgjuesit të saj dhe politika e aksesit të vetë shërbimit HTTP ose SOCKS. Një hyrje SSH vërteton krijuesin e tunelit; nuk vërteton çdo thirrës të mëvonshëm të një dëgjuesi të përbashkët dhe nuk shton një sfidë fjalëkalimi SOCKS.
Nëse një thirrës në distancë ende nuk mund të lidhet, inspektoni adresën e bind, kufizimet e përcjelljes së serverit dhe rrugën e firewall-it në atë rend. Pasi TCP arrin dëgjuesin, një shtrëngim duar i proxy-t i dështuar është një problem i mëvonshëm.