Perché un listener proxy SSH inverso è raggiungibile solo sul server
Controllate l’indirizzo di bind del listener remoto e la modalità GatewayPorts prima di modificare il protocollo del proxy o le credenziali.
Un inoltro remoto può funzionare dal server SSH ma rifiutare connessioni da un’altra macchina perché ascolta solo su loopback. Controllate prima l’indirizzo di ascolto effettivo.
Lato server GatewayPorts | Bind dell’inoltro remoto |
|---|---|
no, il valore predefinito | Limita i listener a loopback |
yes | Forza il bind con wildcard |
clientspecified | Consente al client di richiedere un indirizzo di bind specifico |
Per un listener destinato a un’unica interfaccia controllata, il server può usare:
GatewayPorts clientspecifiedIl client richiede quindi un indirizzo adatto nella propria specifica -R. Quell’indirizzo deve esistere sulla macchina remota e le altre restrizioni di inoltro restano valide. L’opzione -g lato client non è un controllo intercambiabile per questa direzione.
Tre autorizzazioni restano distinte: l’autorizzazione SSH a creare l’inoltro, l’accesso di rete al suo listener e la policy di accesso propria del servizio HTTP o SOCKS. Un accesso SSH autentica il creatore del tunnel; non autentica ogni successivo chiamante di un listener condiviso né aggiunge una richiesta di password SOCKS.
Se un chiamante remoto non riesce ancora a connettersi, ispezionate l’indirizzo di bind, le restrizioni di inoltro del server e il percorso del firewall in quest’ordine. Una volta che TCP raggiunge il listener, una stretta di mano proxy fallita è un problema successivo.