SSH-Portweiterleitung, lokale Portweiterleitung, Remote-Portweiterleitung, dynamische Portweiterleitungsdetails

Teil 1 Übersicht über die SSH-Portweiterleitung

Haben Sie beim Nutzen des kostenlosen WLANs in einem Café schon einmal daran gedacht, dass jemand Ihre Passwörter und privaten Daten stehlen könnte? Fühlen Sie sich elend, wenn Sie feststellen, dass die Labor-Firewall Ihren Netzwerkanwendungsport blockiert? Sehen wir uns an, welche Vorteile uns die Portweiterleitungsfunktion von SSH bringen kann!

Übersicht zur SSH-Portweiterleitung

Lassen Sie uns zunächst das Konzept der Portweiterleitung verstehen. Wir wissen, dass SSH alle Netzwerkdaten zwischen dem SSH-Client und dem Server automatisch verschlüsselt und entschlüsselt. SSH bietet jedoch auch eine sehr nützliche Funktion, nämlich die Portweiterleitung.

Es kann Netzwerkdaten von anderen TCP-Ports über SSH-Links weiterleiten und automatisch entsprechende Verschlüsselungs- und Entschlüsselungsdienste bereitstellen. Dieser Vorgang wird manchmal als „Tunneling“ bezeichnet, da SSH einen sicheren Übertragungskanal für andere TCP-Links bereitstellt.

Beispielsweise können TCP-Anwendungen wie Telnet, SMTP und LDAP davon profitieren, da die Übertragung von Benutzernamen, Passwörtern und privaten Informationen im Klartext vermieden wird. Wenn gleichzeitig die Firewall in Ihrer Arbeitsumgebung die Verwendung einiger Netzwerkports einschränkt, SSH-Verbindungen jedoch zulässt, können Sie durch Weiterleiten des TCP-Ports auch SSH zur Kommunikation verwenden.

Im Allgemeinen kann die SSH-Portweiterleitung zwei Hauptfunktionen bereitstellen:

Verschlüsseln Sie die Kommunikationsdaten zwischen SSH-Client und SSH-Server.

Durchbrechen Sie die Firewall-Einschränkungen und stellen Sie einige TCP-Verbindungen her, die zuvor nicht hergestellt werden konnten.

Abbildung 1. SSH-Portweiterleitung

Wie in der obigen Abbildung gezeigt, kommunizieren die TCP-Ports A und B nach Verwendung der Portweiterleitung nicht mehr direkt, sondern werden zur Kommunikation an den SSH-Client und -Server weitergeleitet, wodurch automatisch eine Datenverschlüsselung erreicht und Firewall-Einschränkungen umgangen werden.

Teil 2 SSH-lokale Portweiterleitung und Remote-Portweiterleitung

Beispielanalyse für die lokale SSH-Portweiterleitung

Schauen wir uns das erste Beispiel an. Im Labor gibt es einen LDAP-Server (LdapServerHost), aber dieser ist auf Anwendungen beschränkt, die auf dem lokalen Computer installiert sind und eine direkte Verbindung zu diesem LDAP-Server herstellen können.

Wenn wir zu Debugging- oder Testzwecken vorübergehend von einem Remotecomputer (LdapClientHost) aus eine direkte Verbindung zu diesem LDAP-Server herstellen möchten, gibt es eine Möglichkeit, dies zu erreichen?

Die Antwort ist zweifellos die lokale Portweiterleitung. Das Befehlsformat lautet:

ssh -L <local port>:<remote host>:<remote port> <SSH hostname>

Führen Sie beispielsweise den folgenden Befehl auf LdapClientHost aus, um eine lokale SSH-Portweiterleitung einzurichten:

$ ssh -L 7001:localhost:389 LdapServerHost


Abbildung 2. Lokale Portweiterleitung

Es ist zu beachten, dass wir in diesem Beispiel Port 7001 als lokalen Abhörport ausgewählt haben. Beachten Sie bei der Auswahl der Portnummer, dass Nicht-Administratorkonten nicht das Recht haben, die Ports 1-1023 zu binden. Wählen Sie daher im Allgemeinen eine Portnummer zwischen 1024 und 65535, die noch nicht verwendet wurde.

Dann können wir die Anwendung auf dem Remote-Computer (LdapClientHost) direkt auf Port 7001 des lokalen Computers konfigurieren (anstelle von Port 389 des LDAP-Servers). Der Datenfluss sieht dann folgendermaßen aus:

Unsere Anwendung auf LdapClientHost sendet Daten an Port 7001 des lokalen Computers.

Der lokale SSH-Client verschlüsselt die auf Port 7001 empfangenen Daten und leitet sie an den SSH-Server von LdapServertHost weiter.

Der SSH-Server entschlüsselt die empfangenen Daten und leitet sie an den lauschenden LDAP-Port 389 weiter.

Abschließend werden die von LDAP zurückgegebenen Daten zurückgegeben, um den gesamten Vorgang abzuschließen.

Wir können sehen, dass die gesamte Prozessanwendung nicht direkt mit dem LDAP-Server verbunden ist, sondern mit einem lokalen Abhörport, aber die SSH-Portweiterleitung ist abgeschlossen

Der ganze Rest wird erledigt: Verschlüsselung, Weiterleitung, Entschlüsselung und Kommunikation.

Dabei sind einige Dinge zu beachten:

Die SSH-Portweiterleitung wird über eine SSH-Verbindung hergestellt und wir müssen diese SSH-Verbindung aufrechterhalten, damit die Portweiterleitung wirksam wird. Sobald diese Verbindung geschlossen wird, wird auch die entsprechende Portweiterleitung geschlossen.

Wir können beim Herstellen einer SSH-Verbindung nur eine Portweiterleitung erstellen, aber wir können einer bestehenden SSH-Verbindung keine Portweiterleitung hinzufügen.

Sie fragen sich vielleicht, warum <remote host> im obigen Befehl localhost verwendet. Auf welche Maschine verweist es? In diesem Fall verweist es auf LdapServertHost. Warum verwenden wir localhost anstelle einer IP-Adresse oder eines Hostnamens?

Tatsächlich hängt dies davon ab, wie wir LDAP zuvor so eingeschränkt haben, dass nur der lokale Computer darauf zugreifen kann.

Wenn nur der Zugriff auf die Lookback-Schnittstelle erlaubt ist, kann natürlich nur localhost oder IP 127.0.0.1 darauf zugreifen und die echte IP oder der Hostname können nicht verwendet werden.

Müssen <remote host> und <SSH hostname> im Befehl dieselbe Maschine sein? Tatsächlich ist dies nicht unbedingt der Fall, es können auch zwei verschiedene Maschinen sein. Dies werden wir in den folgenden Beispielen genauer erläutern.

OK, wir haben die Portweiterleitung in LdapClientHost eingerichtet, aber kann diese Portweiterleitung von anderen Maschinen verwendet werden? Können wir beispielsweise einen neuen LdapClientHost2 hinzufügen, um eine direkte Verbindung mit Port 7001 von LdapClientHost herzustellen?

Die Antwort ist nein. In gängigen SSH-Implementierungen ist die lokale Portweiterleitung an die Lookback-Schnittstelle gebunden, was bedeutet, dass nur localhost oder 127.0.0.1 die lokale Portweiterleitung verwenden können.

Bei Verbindungen, die von anderen Rechnern initiiert werden, erfolgt lediglich die Meldung „Verbindung abgelehnt“.

Glücklicherweise bietet SSH auch das Schlüsselwort GatewayPorts, das wir angeben können, um diese lokale Portweiterleitung mit anderen Maschinen zu teilen.

ssh -g -L <local port>:<remote host>:<remote port> <SSH hostname>


Beispielanalyse für die SSH-Remote-Portweiterleitung

Schauen wir uns ein zweites Beispiel an. Dieses Mal gehen wir davon aus, dass wir aus Netzwerk- oder Firewallgründen keine direkte SSH-Verbindung vom LdapClientHost zum LDAP-Server (LdapServertHost) herstellen können, die umgekehrte Verbindung jedoch zulässig ist. Dann ist unsere Wahl zu diesem Zeitpunkt natürlich die Remote-Portweiterleitung.

Das Befehlsformat ist:

ssh -R <local port>:<remote host>:<remote port> <SSH hostname>


Führen Sie beispielsweise den folgenden Befehl auf dem LDAP-Server (LdapServertHost) aus:

$ ssh -R 7001:localhost:389 LdapClientHost


Abbildung 3. Remote-Portweiterleitung

Im Vergleich zur lokalen Portweiterleitung sind in diesem Diagramm die Positionen von SSH-Server und SSH-Client vertauscht, der Datenfluss bleibt jedoch derselbe.

Unsere Anwendung auf LdapClientHost sendet Daten an Port 7001 des lokalen Computers, und der lokale SSH-Server verschlüsselt die auf Port 7001 empfangenen Daten und leitet sie an den SSH-Client von LdapServertHost weiter.

Der SSH-Client entschlüsselt die empfangenen Daten, leitet sie an den lauschenden LDAP-Port 389 weiter und gibt schließlich die von LDAP zurückgegebenen Daten zurück, um den gesamten Vorgang abzuschließen.

Sind Sie nach der Lektüre etwas verwirrt? Warum wird es als lokale Weiterleitung und manchmal als Remote-Weiterleitung bezeichnet? Was ist der Unterschied zwischen den beiden?

Vergleich und Analyse der lokalen SSH-Portweiterleitung und der Remote-SSH-Portweiterleitung

Ja, SSH-Server, SSH-Client, LdapServertHost, LdapClientHost, lokale Portweiterleitung, Remote-Portweiterleitung,

So viele Substantive können die Leute tatsächlich verwirren.

Lassen Sie uns die Struktur analysieren.

Zunächst einmal erfordert die SSH-Portweiterleitung natürlich eine SSH-Verbindung, und eine SSH-Verbindung ist gerichtet, vom SSH-Client zum SSH-Server.

Unsere Anwendungen haben auch Richtungen. Wenn wir beispielsweise eine Verbindung zu einem LDAP-Server herstellen müssen, ist der LDAP-Server natürlich die Serverseite, und die Richtung unserer Anwendungsverbindung verläuft ebenfalls von der Clientseite der Anwendung zur Serverseite der Anwendung.

Wenn die Richtungen der beiden Verbindungen gleich sind, dann spricht man von einer lokalen Weiterleitung. Und wenn die beiden Richtungen inkonsistent sind, sprechen wir von einer Remote-Portweiterleitung.

Zum Vergleich können wir die beiden obigen Beispiele noch einmal aufrufen.

Beim Weiterleiten lokaler Ports:

LdapClientHost ist sowohl der Client der Anwendung als auch der SSH-Client. Beide Verbindungen verweisen von ihm auf LdapServertHost (sowohl der LDAP-Server als auch der SSH-Server).

Beim Weiterleiten eines Remote-Ports:

LdapClientHost ist der Client der Anwendung, aber ein SSH-Server, während LdapServertHost der Server von LDAP ist, aber ein SSH-Client. Auf diese Weise sind die Richtungen der beiden Verbindungen genau entgegengesetzt.

Eine weitere einfache Möglichkeit, sich zu erinnern, ist

Die Ports auf der Serverseite sind alle vordefinierte feste Ports (Port 22 für SSH-Server, Port 389 für LDAP), während die Ports auf der Clientseite alle dynamische Ports sind, die wir auswählen können (wie im obigen Beispiel Port 7001).

Wenn sich beide Ports auf der Serverseite auf derselben Maschine befinden und beide Ports auf der Clientseite auf einer anderen Maschine, handelt es sich um eine lokale Portverbindung.

Wenn diese vier Ports auf zwei Maschinen verteilt sind und jede Maschine über einen Server-Port und einen Client-Port verfügt, handelt es sich um eine Remote-Port-Verbindung.

Nachdem wir nun den Unterschied zwischen den beiden herausgefunden haben, schauen wir uns ihre Gemeinsamkeiten an.

Wenn Ihre Umgebung sowohl LdapClientHost das Initiieren von SSH-Verbindungen zu LdapServerHost als auch LdapServerHost das Initiieren von SSH-Verbindungen zu LdapClientHost ermöglicht.

Derzeit können wir zwischen lokaler und Remote-Weiterleitung wählen, wodurch dieselbe Funktion erreicht werden kann.

Als Nächstes schauen wir uns eine erweiterte Version der Portweiterleitung an.

Die verschiedenen Verbindungen/Weiterleitungen, die wir zuvor behandelt haben, betrafen nur zwei Maschinen. Erinnern Sie sich an das Problem, das wir bei der lokalen Weiterleitung erwähnt haben?

Können <remote host> und <SSH hostname> im Befehl zur lokalen Portweiterleitung unterschiedliche Maschinen sein?

ssh -L <local port>:<remote host>:<remote port> <SSH hostname>

Die Antwort ist ja! Sehen wir uns ein Beispiel mit vier Maschinen (A, B, C, D) an.

Abbildung 4. Multi-Host-Weiterleitungsanwendung

Führen Sie die folgenden Befehle im SSH-Client (C) aus, um eine SSH-Verbindung und Portweiterleitung herzustellen:

$ ssh -g -L 7001:<B>:389 <D>


Konfigurieren Sie dann den Port 7001 der Verbindungsmaschine (C) auf unserem Anwendungsclient (A).

Beachten Sie, dass wir im Befehl den Parameter „-g“ angegeben haben, um Maschine (A) die Verwendung der von Maschine (C) eingerichteten lokalen Portweiterleitung zu ermöglichen.

Ein weiterer erwähnenswerter Punkt ist, dass bei den obigen Verbindungen die Verbindungen zwischen (A) <-> (C) und (B) <-> (D) keine sicheren Verbindungen sind und nicht durch SSH verschlüsselt oder entschlüsselt werden.

Wenn das Netzwerk zwischen ihnen nicht vertrauenswürdig ist, müssen wir bei der Verwendung dieser Verbindungsmethode vorsichtig sein.

Teil 3. Andere Arten der Portweiterleitung

Beispielanalyse für dynamische SSH-Portweiterleitung

Nun, dynamische Weiterleitung klingt cool.

Haben Sie beim Anblick dieser Zeilen schon einmal daran gedacht, dass wir bereits über lokale Weiterleitung und Remote-Weiterleitung gesprochen haben, die Voraussetzung jedoch darin besteht, dass eine feste Anwendungsserver-Portnummer vorhanden sein muss?

Beispielsweise der LDAP-Server-Port 389 im vorherigen Beispiel. Was ist, wenn keine Portnummer vorhanden ist? usw,

Welche Art von Anwendung hätte diese Portnummer nicht? Beispielsweise die Verwendung eines Browsers zum Surfen im Internet, etwa MSN usw.

Wenn wir in einer unsicheren WiFi-Umgebung im Internet surfen, ist es zweifellos notwendig, die dynamische SSH-Weiterleitung zu verwenden, um unser Surfverhalten und unsere MSN-Informationen zu schützen. Schauen wir uns zunächst das Befehlsformat für die dynamische Weiterleitung an:

$ ssh -D <local port> <SSH Server>


Zum Beispiel:

$ ssh -D 7001 <SSH Server>


Abbildung 5. Dynamische Portweiterleitung

Es scheint einfach. Wir wählen immer noch 7001 als lokale Portnummer. Tatsächlich erstellt SSH hier einen SOCKS-Proxy-Dienst. Werfen wir einen Blick auf die Beschreibung des Parameters -D in der Hilfedokumentation:

-D-Anschluss
Dies funktioniert durch die Zuweisung eines Sockets zum Abhören des Ports auf dem lokalen
Seite, und wenn eine Verbindung zu diesem Port hergestellt wird, wird die
Die Verbindung wird über den sicheren Kanal weitergeleitet und die Anwendung
Das Protokoll wird dann verwendet, um zu bestimmen, von wo aus eine Verbindung hergestellt werden soll.
der Remote-Rechner. Derzeit sind die Protokolle SOCKS4 und SOCKS5
werden unterstützt und ssh fungiert als SOCKS-Server. Nur root
können privilegierte Ports weiterleiten. Dynamische Portweiterleitungen können auch
in der Konfigurationsdatei angegeben werden.

Die anschließende Verwendung ist einfach. Wir können localhost:7001 direkt als normalen SOCKS-Proxy verwenden und ihn direkt auf dem Browser oder MSN einrichten.

Websites, die über den SSH-Client nicht zugänglich waren, können jetzt normal durchsucht werden. Es ist zu beachten, dass der Umfang des SSH-Schutzes derzeit nur die Verbindung vom Browser (SSH-Client) zum SSH-Server umfasst und nicht die Verbindung vom SSH-Server zur Zielwebsite.

Wenn die Sicherheit der zweiten Verbindungshälfte nicht vollständig gewährleistet werden kann, ist dieser Ansatz dennoch keine geeignete Lösung.

Beispielanalyse der Portweiterleitung für das X-Protokoll

Ok, schauen wir uns ein letztes Beispiel an – X-Protokoll-Weiterleitung.

Bei unserer täglichen Arbeit melden wir uns häufig remote bei Linux-/Unix-/Solaris-/HP-Rechnern an, um Entwicklungs- oder Wartungsarbeiten durchzuführen. Außerdem müssen wir häufig einige Programme im GUI-Modus ausführen, z. B. wenn eine grafische Benutzeroberfläche für die Installation von DB2/WebSphere usw. erforderlich ist.

Hierfür gibt es normalerweise zwei Möglichkeiten: VNC oder X Windows, schauen wir uns Letzteres an.

Für die Verwendung von X Window sind normalerweise die separaten Installationen von X-Client und X-Server erforderlich.

In diesem Beispiel ist unser X-Client das Remote-Linux/Unix/Solaris/HP, auf das zugegriffen wird, und unser X-Server ist die lokale Maschine, die den Zugriff initiiert (z. B. der Laptop oder Desktop, den Sie vor sich verwenden).

Um das X-Fenster des X-Clients auf dem X-Server anzuzeigen, müssen Sie zunächst den Standort des X-Servers auf dem X-Client angeben. Das Befehlsformat lautet wie folgt:

export DISPLAY=<X Server IP>:<display #>.<virtual #>


Zum Beispiel:

export DISPLAY=myDesktop:1.0


Führen Sie dann einfach die X-Anwendung aus und das X-Fenster wird automatisch auf Ihrem lokalen Ende geöffnet.

Alles lief problemlos, doch dann installierte die IT-Abteilung plötzlich eine Firewall vor den Remote-Linux-/Unix-/Solaris-/HP-Systemen.

Leider ist Protokoll X nicht in der Liste der zulässigen Protokolle. was zu tun? Ist VNC die einzige Option? Nein, tatsächlich ist dies mithilfe der SSH-Portweiterleitung möglich und die X-Kommunikationsdaten werden gleichzeitig verschlüsselt. So schlagen Sie zwei Fliegen mit einer Klappe.

(Natürlich sollten Sie vor der Verwendung dieser Methode am besten die zuständige IT-Abteilung konsultieren, um zu prüfen, ob sie den entsprechenden Sicherheitsbestimmungen entspricht, um illegale Vorgänge zu vermeiden.)

Auch das Einrichten des Befehls ist sehr einfach. Initiieren Sie einfach eine SSH-Verbindung vom lokalen Rechner (X-Server-Seite) wie folgt:

$ ssh -X <SSH Server>


Abbildung 5. X-Weiterleitung

Nachdem die Verbindung hergestellt ist, können Sie die Remote-X-Anwendung direkt ausführen. Beachten Sie, dass nach dem Einrichten der X-Weiterleitung die Umgebungsvariable DISPLAY automatisch festgelegt wird, normalerweise auf localhost:10.0. Wir müssen und sollten diese Umgebungsvariable nach dem Herstellen der Verbindung nicht ändern.

Ein häufiges Szenario ist, dass unser lokaler Rechner ein Windows-Betriebssystem ist. In diesem Fall können wir den Open Source XMing als unseren XServer wählen und einen beliebigen SSH-Client verwenden. PuTTY und Cygwin können beispielsweise so konfiguriert werden, dass beim Zugriff auf SSH eine X-Weiterleitung eingerichtet wird.

Teil 4 Zusammenfassung der SSH-Portweiterleitung

Bisher haben wir die Einführung der lokalen Portweiterleitung, der Remote-Portweiterleitung, der dynamischen Portweiterleitung und der X-Weiterleitung abgeschlossen.

Im Nachhinein besteht die grundsätzliche Idee darin, die Datenverschlüsselung zu lösen und die verschiedenen Einschränkungen der Firewall zu durchbrechen, indem die TCP-Verbindung an den SSH-Kanal weitergeleitet wird.

Für einige Anwendungen mit bekannten Portnummern, wie z. B. Telnet/LDAP/SMTP, können wir zum Erreichen dieses Ziels die lokale oder Remote-Portweiterleitung verwenden.

Durch dynamische Portweiterleitung kann ein SOCKS-Proxy implementiert werden, um Firewall-Einschränkungen beim Surfen im Internet zu verschlüsseln und zu umgehen.

Für X-Anwendungen ist die X-Weiterleitung zweifellos am besten geeignet. Obwohl wir die einzelnen Teile nur kurz vorgestellt haben,

Aber wenn wir diese Techniken flexibel anwenden können, glaube ich, dass sie uns in unserem täglichen Leben/bei der Arbeit hilfreich sein werden.

Für weitere Artikel zur SSH-Portweiterleitung klicken Sie bitte auf die folgenden verwandten Artikel