Visuelle Anleitung zu SSH-Tunneln / Sudo Null IT News

Notiz. Übersetzer: Der Autor des Artikels betrachtet praktische Szenarien und Beispiele für die Organisation von SSH-Tunneln. Und für eine visuellere Erklärung der Funktionsweise zeigt es Verkehrsströme grafisch an.

SSH-Tunnel sind verschlüsselte TCP-Verbindungen zwischen SSH-Clients und -Servern. Der Verkehr tritt auf der einen Seite des Tunnels ein und auf der anderen Seite transparent wieder aus. Dieser Begriff bezog sich ursprünglich auf Tunnel auf virtuellen TUN/TAP-Netzwerkschnittstellen, wird heute jedoch allgemein als SSH-Portweiterleitung bezeichnet.

So sieht beispielsweise das Reverse-Tunnel-Schema aus, bei dem auf Port 80 des SSH-Clients über den SSH-Server von einer bestimmten IP-Adresse (1.2.3.4) zugegriffen wird:

Hier und unten sind alle Diagramme dem Originalartikel entnommen.Hier und unten sind alle Diagramme dem Originalartikel entnommen.

Tunnelnutzungsszenarien*:

  • Bereitstellung verschlüsselter Kanäle für Protokolle, die Daten im „Klartext“ übertragen.

  • Öffnen von Hintertüren zu privaten Netzwerken.

  • Firewalls umgehen.

*. Notiz

Die Liste wird ergänzt. Fühlen Sie sich frei, Beispiele oder Korrekturen vorzuschlagen
auf GitHub.

Port-Weiterleitung

Leitet einen Port von einem System (lokal oder entfernt) an ein anderes weiter.

Lokale Portweiterleitung

Mit der lokalen Portweiterleitung können Sie Datenverkehr von einem SSH-Client über einen SSH-Server an einen Zielhost umleiten. Mit anderen Worten, Sie können über eine verschlüsselte Verbindung auf entfernte Dienste zugreifen, als wären sie lokal. Anwendungsbeispiele:

  • Zugriff auf einen Remote-Dienst (Redis, Memcached usw.) über eine interne IP-Adresse;

  • lokaler Zugriff auf Ressourcen, die in einem privaten Netzwerk gehostet werden;

  • transparentes Proxying einer Anfrage an einen entfernten Dienst.

Remote-Portweiterleitung

Mit der Remote-Portweiterleitung können Sie den Datenverkehr von einem SSH-Server entweder über einen SSH-Client oder über einen anderen Remote-Host an sein Ziel leiten. Ermöglicht Benutzern in öffentlichen Netzwerken den Zugriff auf Ressourcen in privaten Netzwerken. Anwendungsbeispiele:

  • Öffnen des Zugangs zu einem lokalen Entwicklungsserver über ein öffentliches Netzwerk;

  • Gewähren von IP-beschränktem Zugriff auf eine Remote-Ressource in einem privaten Netzwerk.

Dynamische Portweiterleitung

Bei der dynamischen Portweiterleitung wird auf dem SSH-Client ein SOCKS-Proxy eingerichtet, um den TCP-Datenverkehr über den SSH-Server an den Remote-Host umzuleiten.

Weiterleitung von (privilegierten) Systemports

Um Datenverkehr von Systemports (1-1023) weiterzuleiten, müssen Sie SSH als Root auf dem System ausführen, auf dem der Port geöffnet ist.

sudo ssh -L 80:example.com:80 ssh-server

SSH-Befehlszeilen-Flags

Im Folgenden finden Sie einige nützliche Flags beim Erstellen von Tunneln:

-f # versetzt den ssh-Prozess in den Hintergrund; -n # verhindert das Lesen von STDIN; -N # Keine Remote-Befehle ausführen. Nützlich, wenn Sie nur Ports weiterleiten müssen; -T # bricht die Terminal-Neuzuordnung ab.

Hier ist ein Beispielbefehl zum Erstellen eines SSH-Tunnels im Hintergrund und zum Weiterleiten eines lokalen Ports über den SSH-Server:

ssh -fnNT -L 127.0.0.1:8080:example.org:80 ssh-server

Der Kürze halber werden die folgenden Beispiele ohne Befehlszeilen-Flags gezeigt.

Lokale Portweiterleitung

Umleiten von Verbindungen vom Port des lokalen Systems zum Port des Remote-Hosts:

ssh -L 127.0.0.1:8080:example.org:80 ssh-server

Leitet lokale Verbindungen um 127.0.0.1:8080 an Port 80 beispiel.org über SSH-Server. Der Datenverkehr zwischen dem lokalen System und dem SSH-Server wird durch den SSH-Tunnel geleitet. Verkehr zwischen SSH-Server und beispiel.org – Nein. In Hinsicht auf beispiel.org Der Datenverkehr kommt vom SSH-Server.

ssh -L 8080:beispiel.org:80 ssh-serverssh -L *:8080:beispiel.org:80 ssh-server

Die obigen Befehle geben Zugriff auf beispiel.org:80 über einen SSH-Tunnel für Verbindungen auf Port 8080 auf allen Schnittstellen des lokalen Systems.

ssh -L 192.168.0.1:5432:127.0.0.1:5432 ssh-Server

Leitet Verbindungen um von 192.168.0.1:5432 auf dem lokalen System 127.0.0.1:5432 auf dem SSH-Server. Bitte beachten Sie das hier 127.0.0.1 – localhost aus Sicht des SSH-Servers.

SSH-Konfigurationen

Stellen Sie sicher, dass die TCP-Weiterleitung auf dem SSH-Server aktiviert ist (sollte standardmäßig aktiviert sein). Überprüfen Sie den Eintrag in der Datei /etc/ssh/sshd_config:

AllowTcpForwarding ja

Beim Weiterleiten von Ports an andere Schnittstellen als 127.0.0.1GatewayPorts müssen auf dem lokalen System aktiviert sein (in /etc/ssh/ssh_config oder auf der Kommandozeile):

GatewayPorts jaVerwendungsszenarien

Geeignet für Fälle, in denen eine sichere Verbindung erforderlich ist, um auf einen Remotedienst zuzugreifen, der mit unverschlüsselten Daten arbeitet. Beispielsweise verwenden Redis und Memcached Protokolle, die auf Klartextdaten basieren.

Wenn der sichere Zugriff auf einen dieser Dienste auf einem entfernten Server über öffentliche Netze organisiert ist, können Sie einen Tunnel vom lokalen System zu diesem Server aufbauen.

Remote-Portweiterleitung

Leitet einen Port auf einem entfernten System an ein anderes System weiter.

ssh -R 8080:localhost:80 ssh-server

Leitet Datenverkehr vom SSH-Serverport 8080 für alle Schnittstellen an Port um lokaler Host: 80 auf dem lokalen Rechner. Wenn eine der Schnittstellen dem Internet zugewandt ist, wird der für Port 8080 bestimmte Datenverkehr an das lokale System umgeleitet.

ssh -R 1.2.3.4:8080:localhost:80 ssh-server

Leitet Datenverkehr vom SSH-Serverport 8080 um lokaler Host: 80 auf dem lokalen System, während der Zugriff auf den Eingang zum SSH-Tunnel von der Serverseite nur von der IP-Adresse erlaubt ist 1.2.3.4 (Hinweis: Die GatewayPorts-Direktive muss auf clientpecified gesetzt sein).

Notiz. Übersetzer: hier könnte ein Fehler vorliegen. Flagge -R – Das Bindungsadresse, indem Sie die IP-Adresse auf dem Computer auswählen, auf dem der SSH-Server den Port überwacht. Dementsprechend sollte es anstelle eines kleinen Mannes mit IP kleine Männer geben und stattdessen ssh_server:8080 sollte sein 1.2.3.4:8080.

ssh -R 8080:example.org:80 ssh-server

Leitet Datenverkehr vom SSH-Serverport 8080 für alle Schnittstellen weiter lokaler Host: 80 auf dem lokalen System. Als nächstes wird der Datenverkehr vom lokalen System dorthin geleitet beispiel.org:80. In Hinsicht auf beispiel.org die Verkehrsquelle ist das lokale System.

Konfiguration des SSH-Servers

Der SSH-Server wird in /etc/ssh/sshd_config konfiguriert.

Standardmäßig sind weitergeleitete Ports nicht über das Internet zugänglich. Um den öffentlichen Internetverkehr auf den lokalen Computer umzuleiten, fügen Sie die folgende Zeile zu sshd_config auf dem Remote-Server hinzu:

Gateway-Ports ja

Sie können auch in sshd_config angeben, welche Clients Zugriff haben:

Clientspezifische GatewayPorts

Dynamische Portweiterleitung

Umleiten des Datenverkehrs von mehreren Ports zu einem Remote-Server.

ssh -D 3000 ssh-Server

Der obige Befehl erstellt einen SOCKS-Proxy auf Port 3000 für alle Schnittstellen auf dem lokalen System. Jetzt kann der Datenverkehr, der über einen Proxyserver an einen SSH-Server gesendet wird, an jeden Port oder Zielhost adressiert werden. Das Standardprotokoll ist SOCKS5, das TCP und UDP unterstützt.

ssh -D 127.0.0.1:3000 ssh-server

Löst einen SOCKS-Proxy aus 127.0.0.1:3000 auf dem lokalen System.

Wenn ein SOCKS-Proxy ausgeführt wird, können Sie den Browser so konfigurieren, dass er für den Zugriff auf Ressourcen verwendet wird, als kämen die Verbindungen von einem SSH-Server. Wenn Ihr SSH-Server beispielsweise Zugriff auf andere Server in Ihrem privaten Netzwerk hat, können Sie einen SOCKS-Proxy verwenden, um lokal auf diese Server zuzugreifen (als ob Sie sich im selben Netzwerk befänden), ohne ein VPN einrichten zu müssen.

Die Funktion des SOCKS-Proxys kann mit dem Befehl überprüft werden:

curl -x socks5://127.0.0.1:12345 https://example.org

SSH-Client-Konfiguration

Der SSH-Client wird in /etc/ssh/ssh_config konfiguriert.

Aktivieren Sie GatewayPorts auf dem System, um anderen Schnittstellen den Zugriff auf den SOCKS-Proxy zu ermöglichen:

Gateway-Ports ja

Da GatewayPorts auf dem SSH-Client konfigurierbar ist, können Sie Befehlszeilenoptionen anstelle von ssh_config verwenden, um Folgendes zu konfigurieren:

ssh -o GatewayPorts=yes -D 3000 ssh-server

Jump-Hosts und Proxy-Befehle

Transparente Verbindung zu einem entfernten Host über eine Zwischenverbindung.

ssh -J user1@jump-host user2@remote-hostssh -o “ProxyJump user1@jump-host” user2@remote-host

Stellt eine SSH-Verbindung zum Jump-Host her und leitet den Datenverkehr an den Remote-Host weiter.

Stellt über einen zwischengeschalteten Jump-Host eine Verbindung zu einem entfernten Host her. Der obige Befehl sollte sofort funktionieren, wenn der Jump-Host bereits SSH-Zugriff auf den Remote-Host hat. Wenn nicht, können Sie die Agentenweiterleitung verwenden, um einen SSH-Schlüssel von Ihrem lokalen Computer an einen Remote-Host weiterzuleiten.

ssh -J jump-host1,jump-host2 ssh-server

Sie können mehrere Jump-Hosts durch Kommas getrennt angeben.

ssh -o ProxyCommand=”nc -X 5 -x localhost:3000 %h %p” user@remote-host

Verbindung zu einem Remote-Server über SOCKS5 mit netcat. Aus Sicht des Servers gehört die IP-Adresse des Absenders dem Proxy-Host. Dabei wird eine Ende-zu-Ende-Verschlüsselung für die SSH-Verbindung verwendet, sodass der Proxy-Host nur verschlüsselten Datenverkehr zwischen dem lokalen System und dem Remote-Host sieht.

SSH-Client-Konfiguration

Der SSH-Client wird in /etc/ssh/ssh_config konfiguriert.

Um die Agentenweiterleitung zu verbinden, können Sie dem lokalen SSH-Agenten mit ssh-add einen lokalen SSH-Schlüssel hinzufügen:

ssh hinzufügen

Zuverlässige SSH-Tunnel

Die oben aufgeführten Befehle funktionieren einmalig: Sie erhalten sofort ein bestimmtes Ergebnis, und hier endet ihre Arbeit. Um SSH-Tunnel vor Netzwerkausfällen oder unzuverlässigen Verbindungen zu schützen, müssen Sie daher zusätzliche Konfigurationen vornehmen.

Standardmäßig kann die zum Erstellen eines SSH-Tunnels verwendete TCP-Verbindung nach einer gewissen Zeit der Inaktivität beendet werden. Um dies zu verhindern, müssen Sie den Server (/etc/ssh/sshd_config) so konfigurieren, dass er Heartbeat-Nachrichten sendet:

ClientAliveInterval 15 ClientAliveCountMax 4

Sie können den Client auch so konfigurieren, dass er solche Nachrichten sendet (/etc/ssh/ssh_config):

ServerAliveInterval 15 ServerAliveCountMax 4

Verwenden von AutoSSH

Die obigen Einstellungen können Unterbrechungen aufgrund von Inaktivität verhindern, aber sie sind nicht in der Lage, unterbrochene Verbindungen wiederherzustellen. Um den SSH-Tunnel automatisch neu zu starten, können Sie das Dienstprogramm autossh verwenden – es erstellt einen SSH-Tunnel und überwacht seinen Zustand.

AutoSSH akzeptiert die gleichen Portweiterleitungsoptionen wie SSH:

autossh -R 2222:localhost:22 ssh-server

Dieser Befehl erstellt einen Tunnel, der nach Netzwerkausfällen wiederhergestellt werden kann. Standardmäßig öffnet AutoSSH zusätzliche Ports auf dem SSH-Client/Server für die Zustandsprüfung. Wenn kein Datenverkehr zwischen den Healthcheck-Ports geleitet wird, startet AutoSSH den Tunnel neu.

autossh -R 2222:localhost:22 \ -M 0 \ -o “ServerAliveInterval 10” -o “ServerAliveCountMax 3” \ remote-host

Das Flag -M 0 deaktiviert Gesundheitscheck-Ports (der SSH-Client ist in diesem Fall für die Gesundheitsprüfung verantwortlich). Im obigen Beispiel sollte der Server alle 10 Sekunden Signale senden. Wenn drei aufeinanderfolgende Signale fehlschlagen, wird der SSH-Client beendet und AutoSSH startet einen neuen Tunnel.

Weitere Beispiele und Anwendungsfälle

Transparenter Zugriff auf eine Remote-Ressource in einem privaten Netzwerk.

Angenommen, es gibt ein Git-Repository in einem privaten Netzwerk, auf das nur über einen dedizierten Server in diesem Netzwerk zugegriffen werden kann. Der Server ist nicht mit dem Internet verbunden. Es besteht ein direkter Zugriff auf den Server, jedoch kein VPN-Zugriff auf das private Netzwerk.

Es ist erforderlich, den Zugriff auf das Git-Repository zu öffnen, als ob die Verbindung dazu direkt vom lokalen System ausgehen würde. Wenn Sie SSH-Zugriff auf einen anderen Server haben, auf den sowohl vom lokalen Computer als auch von einem dedizierten Server aus zugegriffen werden kann, können Sie einen SSH-Tunnel erstellen und die ProxyCommand-Anweisungen verwenden.

ssh -L 127.0.0.1:22:127.0.0.1:2222 Zwischenhost

Der obige Befehl leitet Port 2222 auf dem Zwischenhost an Port 22 des dedizierten Servers weiter. Jetzt können Sie sich mit dem SSH-Server auf dem dedizierten Server verbinden, obwohl er nicht über das Internet erreichbar ist.

ssh -p 2222 user@localhost

Für mehr Komfort können Sie Ihrer lokalen ~/.ssh/config einige Anweisungen hinzufügen:

Host git.private.network Hostname git.private.network ForwardAgent ja ProxyCommand ssh private nc %h %p Host privater Hostname localhost Port 2222 Benutzer privater Benutzer ForwardAgent ja ProxyCommand ssh tunnel@intermediate-host nc %h %p

Dadurch erhält der Benutzer Zugriff auf das lokale Git-Repository, als ob er sich in einem privaten Netzwerk befände.

PS

Lesen Sie auch in unserem Blog:

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *