De ce un ascultător de proxy SSH invers este accesibil doar pe server
Verificați adresa de bind a ascultătorului remote și modul GatewayPorts înainte de a schimba protocolul proxy-ului sau credențialele.
Un forward remote poate funcționa de pe serverul SSH dar poate refuza conexiunile de pe altă mașină pentru că ascultă doar pe loopback. Verificați mai întâi adresa reală de ascultare.
Pe partea serverului GatewayPorts | Bind-ul forward-ului remote |
|---|---|
no, implicit | Restrânge ascultătorii la loopback |
yes | Forțează bind-ul wildcard |
clientspecified | Permite clientului să solicite o adresă de bind anume |
Pentru un ascultător destinat unei singure interfețe controlate, serverul poate folosi:
GatewayPorts clientspecifiedClientul solicită apoi o adresă potrivită în specificația sa -R. Acea adresă trebuie să existe pe mașina remote, iar celelalte restricții de forwardare se aplică în continuare. -g din partea clientului nu este un control interschimbabil pentru această direcție.
Trei permisiuni rămân distincte: autorizarea SSH de a crea forward-ul, accesul de rețea la ascultătorul său și politica de acces proprie a serviciului HTTP sau SOCKS. O autentificare SSH îl autentifică pe creatorul tunelului; nu autentifică fiecare apelant ulterior al unui ascultător partajat și nu adaugă o provocare de parolă SOCKS.
Dacă un apelant remote încă nu se poate conecta, inspectați adresa de bind, restricțiile de forwardare ale serverului și traseul firewall-ului în această ordine. După ce TCP ajunge la ascultător, un handshake de proxy eșuat este o problemă ulterioară.