Waarom een reverse SSH-proxylistener alleen op de server bereikbaar is
Controleer het bindadres van de externe listener en de GatewayPorts-modus voordat u het proxyprotocol of de inloggegevens wijzigt.
Een externe doorstuur kan vanaf de SSH-server werken maar verbindingen van een andere machine weigeren, omdat hij alleen op loopback luistert. Controleer eerst het werkelijke luisteradres.
Aan serverzijde GatewayPorts | Binding van externe doorstuur |
|---|---|
no, de standaard | Beperkt listeners tot loopback |
yes | Forceert wildcard-binding |
clientspecified | Laat de client een specifiek bindadres aanvragen |
Voor een listener die bedoeld is voor één gecontroleerde interface kan de server gebruiken:
GatewayPorts clientspecifiedDe client vraagt dan een passend adres aan in zijn -R-specificatie. Dat adres moet op de externe machine bestaan, en andere doorstuurbeperkingen gelden nog steeds. De -g aan clientzijde is geen uitwisselbare besturing voor deze richting.
Drie machtigingen blijven gescheiden: SSH-autorisatie om de doorstuur te maken, netwerktoegang tot de listener en het eigen toegangsbeleid van de HTTP- of SOCKS-dienst. Een SSH-login authenticeert de maker van de tunnel; het authenticeert niet elke latere aanroeper van een gedeelde listener en voegt geen SOCKS-wachtwoorduitdaging toe.
Als een externe aanroeper nog steeds geen verbinding kan maken, inspecteer dan het bindadres, de doorstuurbeperkingen van de server en het firewallpad in die volgorde. Zodra TCP de listener bereikt, is een mislukte proxy-handshake een later probleem.