Warum ein Reverse-SSH-Proxy-Listener nur auf dem Server erreichbar ist
Prüfen Sie die Bind-Adresse des Remote-Listeners und den GatewayPorts-Modus, bevor Sie das Proxy-Protokoll oder Anmeldedaten ändern.
Eine Remote-Weiterleitung kann vom SSH-Server aus funktionieren, aber Verbindungen von einem anderen Rechner ablehnen, weil sie nur auf Loopback lauscht. Prüfen Sie zuerst die tatsächliche Listener-Adresse.
Serverseitig GatewayPorts | Bindung der Remote-Weiterleitung |
|---|---|
no, der Standard | Beschränkt Listener auf Loopback |
yes | Erzwingt Wildcard-Bindung |
clientspecified | Erlaubt dem Client, eine bestimmte Bind-Adresse anzufordern |
Für einen Listener, der auf einer kontrollierten Schnittstelle vorgesehen ist, kann der Server verwenden:
GatewayPorts clientspecifiedDer Client fordert dann eine passende Adresse in seiner -R-Spezifikation an. Diese Adresse muss auf dem Remote-Rechner existieren, und andere Weiterleitungsbeschränkungen gelten weiterhin. Das clientseitige -g ist keine austauschbare Steuerung für diese Richtung.
Drei Berechtigungen bleiben getrennt: die SSH-Autorisierung zum Erstellen der Weiterleitung, der Netzwerkzugriff auf ihren Listener und die eigene Zugriffsrichtlinie des HTTP- oder SOCKS-Dienstes. Eine SSH-Anmeldung authentifiziert den Ersteller des Tunnels; sie authentifiziert nicht jeden späteren Aufrufer eines gemeinsam genutzten Listeners und fügt keine SOCKS-Passwortabfrage hinzu.
Wenn ein entfernter Aufrufer weiterhin keine Verbindung herstellen kann, prüfen Sie die Bind-Adresse, die Weiterleitungsbeschränkungen des Servers und den Firewall-Pfad in dieser Reihenfolge. Sobald TCP den Listener erreicht, ist ein fehlgeschlagener Proxy-Handshake ein späteres Problem.