Wir haben ein Problem beim Herstellen von SSH-Verbindungen über die Remote-Portweiterleitung.
Das Szenario ist ein Unternehmensnetzwerk, bei dem sich ein Server im internen Netzwerk (nennen wir es „Ursprung“) per SSH bei einem Server in der DMZ („Ziel“) anmelden muss. Da der Zielserver in der DMZ für Verbindungen aus dem internen Netzwerk gesperrt ist (und vom internen Netzwerk aus nicht einmal gesehen werden kann), haben wir einen Jump-Host in der DMZ, über den wir gehen („Jumphost“). Dies tun wir, indem wir auf dem Jump-Host eine Remote-Portweiterleitung einrichten.
Wir führen diesen Befehl vom Ursprungsserver im internen Netzwerk zum Jumphost aus:
origin> ssh -R *:1234:target:22 myusername@jumphost
Dies dient zum Herstellen einer SSH-Sitzung auf dem Jumphost, zum Abhören von Port 1234 (nur ein Beispiel für eine beliebige Portnummer) und zum Weiterleiten von Verbindungen auf diesem Port an Port 22 des Zielservers (SSH).
Anschließend bauen wir eine zweite SSH-Sitzung auf, immer noch vom Ursprungsserver zum Jumphost, auf Port 1234, die dann tatsächlich mit dem Zielserver auf Port 22 verbunden wird – dies ist unsere „echte“ SSH-Sitzung, bei der wir unsere Arbeit auf dem Zielserver erledigen können:
origin> ssh jumphost -P 1234
Aufbau
Der Jump-Host wurde mit den folgenden Einstellungen in sshd_config so konfiguriert, dass Remote-Port-Weiterleitung zulässig ist:
AllowTcpForwarding yes
GatewayPorts yes
Außerdem sind zwischen dem Ursprungsserver und dem Jump-Host Firewall-Öffnungen für Port 22 (für die anfängliche SSH-Verbindung zum Einrichten der Remote-Portweiterleitung) und Port 1234 (für die nachfolgende SSH-Verbindung auf dem weitergeleiteten Port) vorhanden. Zwischen dem Jump-Host und dem Ziel gibt es ebenfalls eine Firewall, die auf Port 22 geöffnet wurde.
Ergebnis
Wenn wir die zweite Verbindung herstellen (die über den weitergeleiteten Port), wird die Verbindung sofort geschlossen (,Verbindung vom Remote-Host geschlossen‘).
Das Ausführen von tcpdump auf dem Zielserver zeigt keine Aktivität, d. h. es scheint, als würde die Verbindung blockiert.
Wir können jedoch erfolgreich eine reguläre SSH-Sitzung vom Jumphost zum Ziel aufbauen. Nur beim Eingehen über den weitergeleiteten Port wird die Verbindung geschlossen, obwohl beide über Port 22 mit dem Ziel verbunden sind.
Darüber hinaus gilt: Wenn wir die Portweiterleitung auf einen Server im internen Netzwerk richten (also eine Verbindung vom Ursprung im internen Netzwerk zum Jumphost in der DMZ und zurück zu einem dritten Server im internen Netzwerk), wird die SSH-Sitzung erfolgreich hergestellt.
Spekulationen und Fragen
All dies lässt mich glauben, dass eine Netzwerksicherheitseinstellung im Spiel ist, die eine Verbindung über den weitergeleiteten Port auf dem Jump-Server zum Zielserver innerhalb der DMZ verhindert. Leider bin ich nicht gut genug informiert, um Folgendes zu wissen:
(1) Ist eine SSH-Verbindung, die vom Ursprungsserver über einen weitergeleiteten Port auf dem Jump-Server kommt, aus Sicht der Netzwerksicherheitsrichtlinie so „anders“, dass sie technisch blockiert werden könnte, und wenn ja, wie? Und was müsste getan werden, um diese Einschränkung aufzuheben?
(2) Gibt es andere Gründe dafür, dass diese Verbindung nicht zugelassen wird - Firewall-Konfiguration, Router-Konfiguration, SSH-Einstellungen am Ursprungs- oder Jumphost oder etwas anderes?
(3) Könnte es daran scheitern, dass der Ursprungsserver den Zielserver nicht kennt und der erste SSH-Befehl daher nicht wie vorgesehen funktioniert? Mit anderen Worten: Wird der im ersten SSH-Befehl angegebene Hostname („Ziel“) auf dem Client (Ursprung) oder auf dem Server interpretiert, mit dem wir uns verbinden, um den Tunnel zu erstellen (der Jumphost)?
Was mich am meisten verblüfft, ist, dass eine normale SSH-Sitzung vom Jumphost zum Ziel hergestellt werden kann. Ich würde denken, dass die über den weitergeleiteten Port eingehende SSH-Verbindung dieselbe wäre, aber irgendwie ist das nicht der Fall.
Jeder Beitrag ist sehr willkommen.
Antwort1
Es sieht so aus, als ob Sie lokale Portweiterleitung statt Remote-Portweiterleitung verwenden sollten. Vielleicht möchten Sie den folgenden hilfreichen Blog-Beitrag von Dirk Loss lesen:
Es enthält das folgende erläuternde Diagramm:
Um das Diagramm lesen zu können, müssen Sie wissen, dass es die Beziehungen zwischen vier verschiedenen Rollen beschreibt, die an der Erstellung und Nutzung eines SSH-Tunnels beteiligt sind:
- ein SSH-Client (z
ssh. B. der OpenSSH-Befehlszeilenclient), der zum Herstellen des Tunnels verwendet wird; - ein SSH-Server (d. h
sshd. der OpenSSH-Server-Daemon), der zur Verwaltung des anderen Tunnelendes verwendet wird; - ein Anwendungsserver (z. B. ein anderer SSH-Server oder ein HTTP-Server);
- ein Anwendungsclient (z. B. ein anderer SSH-Client oder ein Webbrowser), der über den Tunnel auf den Anwendungsserver zugreifen möchte.
Es ist auch wichtig zu verstehen, dass die beiden unterschiedlichen Weiterleitungsarten zwei unterschiedlichen Anwendungsfällen entsprechen:
Lokale Weiterleitung: Hier stellt der Anwendungsclient eine Verbindung über den SSH-Client her.
Remote Forwarding: Hier stellt der Anwendungsclient eine Verbindung über den SSH-Server her.
Remote Forwarding wird so genannt, weil die Weiterleitung remote (auf dem SSH-Server) und nicht lokal (auf dem SSH-Client) erfolgt. Ich finde auch, dass „Remote Forwarding = Reverse Forwarding“ eine nützliche Eselsbrücke ist.
Wie Sie sehen, müssen Sie lokale Portweiterleitung verwenden, um eine Verbindung von einem sshClient auf dem originHost über einen sshdServer auf einem Proxy jumphostzu einem dritten Host herzustellen. Remote-Portweiterleitung ist für den Fall gedacht, dass sich der Einstiegspunkt zum Tunnel auf dem Host befinden soll, auf dem der Server läuft, und nicht auf dem Host, auf dem der Client läuft.targetsshdssh
In der Manpage wird die Syntax für die lokale Portweiterleitung wie folgt geschrieben:
ssh -L [bind_address:]port:host:hostport user@remote
Dies kann intuitiver wie folgt geschrieben werden:
ssh -L [local_bind_address:]local_port:remote_host:remote_host_port user@proxy_host
Oder, unter Verwendung Ihrer Namenskonventionen:
ssh -L [origin_bind_address:]origin_port:target_host:target_host_port user@jump_host
Wenn wir Ihren Befehl so ändern, dass stattdessen die lokale Portweiterleitung verwendet wird, erhalten wir Folgendes:
user@origin:~$ ssh -L *:1234:target:22 myusername@jumphost