Per què un oient de proxy SSH invers només és accessible al servidor
Comproveu l'adreça d'enllaç de l'oient remot i el mode GatewayPorts abans de canviar el protocol del proxy o les credencials.
Un reenviament remot pot funcionar des del servidor SSH però rebutjar connexions d'una altra màquina perquè només escolta a loopback. Comproveu primer l'adreça real de l'oient.
Al costat del servidor GatewayPorts | Enllaç del reenviament remot |
|---|---|
no, el valor per defecte | Restringeix els oients a loopback |
yes | Força l'enllaç a qualsevol adreça (wildcard) |
clientspecified | Permet al client demanar una adreça d'enllaç concreta |
Per a un oient destinat a una interfície controlada, el servidor pot utilitzar:
GatewayPorts clientspecifiedDesprés el client demana una adreça adequada a la seva especificació -R. Aquesta adreça ha d'existir a la màquina remota, i les altres restriccions de reenviament encara s'apliquen. El -g del costat del client no és un control intercanviable per a aquesta direcció.
Tres permisos continuen sent diferents: l'autorització SSH per crear el reenviament, l'accés de xarxa al seu oient i la política d'accés pròpia del servei HTTP o SOCKS. L'inici de sessió SSH autentica el creador del túnel; no autentica cada cridador posterior d'un oient compartit ni afegeix un repte de contrasenya SOCKS.
Si un cridador remot encara no es pot connectar, reviseu l'adreça d'enllaç, les restriccions de reenviament del servidor i el camí del tallafoc en aquest ordre. Un cop TCP arriba a l'oient, una negociació de proxy fallida és un problema posterior.