Praxisleitfaden für SSH-Tunnel: lokales und entferntes Port-Forwarding

Kurzüberblick

• SSH-Tunnel sind eine Technik, um sicher auf Dienste zuzugreifen, die von außen nicht direkt erreichbar sind, oder interne Dienste vorübergehend nach außen zu veröffentlichen.
• SSH-Port-Forwarding wird im Wesentlichen in lokales Forwarding, entferntes Forwarding, dynamisches lokales Forwarding und dynamisches entferntes Forwarding unterteilt.
• -L öffnet einen Port auf dem lokalen SSH-Client, -R öffnet einen Port auf dem entfernten SSH-Server.
• Mit einem Bastion Host kann man nicht nur den SSH-Server selbst erreichen, sondern auch andere Dienste in privaten Netzen, auf die dieser Server zugreifen kann.
• Dynamisches Forwarding legt kein festes Ziel fest, sondern erstellt einen SOCKS-Proxy, über den mehrere Hosts und Ports erreichbar sind.
• Wenn entferntes Forwarding für externe Netzwerke freigegeben werden soll, muss die GatewayPorts-Konfiguration des SSH-Servers geprüft werden.

Einleitung

Zweck von SSH-Tunneln

• SSH dient nicht nur zur Ausführung entfernter Befehle, sondern bietet auch eine Tunnel-Funktion, die Netzwerkverkehr verschlüsselt transportiert.

• Ohne separates VPN oder dedizierte Proxy-Software ermöglichen Standard-SSH-Befehle den Zugriff auf private Netze und die Veröffentlichung von Diensten.

• Typische Einsatzfälle sind unter anderem:

  • Zugriff auf interne VPC-Dienste über einen öffentlichen Server
  • Öffnen eines lokalen Ports eines entfernten Entwicklungsservers im Browser auf dem eigenen PC
  • Vorübergehende Veröffentlichung eines Dienstes aus dem Heimnetz oder einem privaten Netz
  • Verbindung des Debugging-Ports eines lokalen Browsers mit einem entfernten Entwicklungsagenten

• Beim Verständnis von SSH-Tunneln sollte man zwei Dinge unterscheiden:

  • Welches Gerät einen neuen Port öffnet und auf Verbindungen wartet
  • Von welchem Gerät aus der durch den Tunnel geleitete Verkehr das Ziel tatsächlich erreicht

Hauptteil

Lokales Forwarding verbindet entfernte Dienste lokal

• Lokales Port-Forwarding verbindet einen entfernten Server oder einen Dienst, den der entfernte Server erreichen kann, mit einem lokalen Port auf dem PC des Benutzers.
• Die grundlegende Befehlsstruktur lautet wie folgt.

ssh -L [local_addr:]local_port:remote_addr:remote_port [user@]sshd_addr  

• Der SSH-Client wartet auf Verbindungen an local_port auf dem PC des Benutzers.

• Datenverkehr, der auf diesem Port eingeht, wird durch den SSH-Tunnel an remote_addr:remote_port weitergeleitet.

• Das endgültige Ziel wird aus der Netzperspektive des SSH-Servers erreicht.

• Wichtige Anwendungsfälle sind unter anderem:

  • Zugriff auf entferntes MySQL, PostgreSQL oder Redis
  • Zugriff auf Webanwendungen, die nur im privaten Netz erreichbar sind
  • Zugriff auf Container-Ports, die nicht über die externe Schnittstelle des Servers veröffentlicht wurden

Ein Bastion Host vermittelt den Zugang zu privaten Netzen

• remote_addr und sshd_addr, also das SSH-Ziel, müssen nicht dasselbe Gerät sein.

• Wenn der SSH-Server andere interne Dienste erreichen kann, lässt sich dieser Server als Vermittlungsstation verwenden.

• Einen solchen Vermittlungsserver nennt man Bastion Host oder Jump Host.

• Eine typische Verbindungsstruktur sieht so aus:

  • SSH-Verbindung vom PC des Benutzers zu einem öffentlichen Bastion Host
  • Weiterleitung des Datenverkehrs zu einem internen VPC-Dienst, den der Bastion Host erreichen kann

• So lassen sich Datenbanken, Such-Cluster oder interne APIs erreichen, die nicht öffentlich zugänglich sind.

Entferntes Forwarding veröffentlicht lokale Dienste auf der Gegenseite

• Entferntes Port-Forwarding verbindet einen Dienst auf dem PC des Benutzers oder in einem internen Netz mit einem Port auf einem externen SSH-Server.
• Die grundlegende Befehlsstruktur lautet wie folgt.

ssh -R [remote_addr:]remote_port:local_addr:local_port [user@]gateway_addr  

• Der entfernte SSH-Server öffnet remote_port und wartet auf Verbindungen.

• Datenverkehr, der auf diesem Port eingeht, wird durch den SSH-Tunnel an local_addr:local_port auf der Seite des SSH-Clients weitergeleitet.

• Wichtige Anwendungsfälle sind unter anderem:

  • Veröffentlichung eines auf dem Laptop laufenden Entwicklungsservers für eine externe Demo
  • Bereitstellung eines Homelab-Dienstes für den Zugriff aus dem Internet
  • Bereitstellung des Debugging-Ports eines lokalen Browsers für eine entfernte Entwicklungsumgebung

Für die externe Veröffentlichung ist die Einstellung GatewayPorts erforderlich

• In der Standardkonfiguration kann ein Port für entferntes Forwarding nur an localhost des SSH-Servers gebunden werden.
• In diesem Fall ist der Dienst auf dem entfernten Server selbst erreichbar, aber nicht von außen zugänglich.
• Wenn der Zugriff über die öffentliche IP des entfernten Servers erfolgen soll, muss in sshd_config folgende Einstellung geprüft werden.

GatewayPorts yes  

• Da diese Einstellung Ports auf externen Schnittstellen freigeben kann, sollten zusätzlich Firewall-Regeln und Zugriffskontrollen angewendet werden.
• Wenn ein Entwicklungsdienst direkt im öffentlichen Internet exponiert wird, steigt das Risiko unautorisierter Zugriffe oder Angriffe.

Das lokale Gerät kann ein Jump Host für ein privates Netz sein

• Das Ziel eines entfernten Forwardings ist nicht auf das Gerät beschränkt, auf dem der SSH-Client selbst läuft.

• Wenn der PC des Benutzers andere Server im Heimnetz erreichen kann, lassen sich auch Ports dieser internen Server über den entfernten SSH-Server veröffentlichen.

• In diesem Fall wird der PC des Benutzers zu einem Vermittlungsgerät zwischen folgenden zwei Netzen:

  • Heimnetz oder privates Entwicklungsnetz
  • Öffentlicher SSH-Gateway-Server

• Damit können Dienste auf Heimservern oder internen Entwicklungsservern, die nicht direkt mit dem Internet verbunden sind, von außen zugänglich gemacht werden.

Dynamisches lokales Forwarding erstellt einen lokalen SOCKS-Proxy

• Gewöhnliches lokales Forwarding bindet einen lokalen Port fest an ein einziges Ziel.
• Dynamisches lokales Forwarding erstellt einen SOCKS-Proxy auf dem SSH-Client.
• Die grundlegende Befehlsstruktur lautet wie folgt.

ssh -D [local_addr:]local_port [user@]sshd_addr  

• Auf dem angegebenen Port des PCs des Benutzers läuft dann ein SOCKS-Proxy.

• Anwendungen mit SOCKS-Unterstützung können bei jeder Verbindung unterschiedliche Zieladressen und Ports angeben.

• Die eigentliche Verbindung zum Ziel wird aus der Netzperspektive des entfernten SSH-Servers hergestellt.

• Der Unterschied zu festem lokalem Forwarding besteht darin, dass sich über eine einzige SSH-Verbindung mehrere Dienste im entfernten privaten Netz erreichen lassen.

• Wichtige Anwendungsfälle sind unter anderem:

  • Aufruf mehrerer interner APIs über einen Bastion Host
  • Erkundung von Webanwendungen innerhalb eines privaten Netzes
  • Zugriff auf mehrere VPC-Endpunkte über eine einzelne EC2-Instanz

Dynamisches entferntes Forwarding erstellt einen entfernten SOCKS-Proxy

• Wenn bei der Option -R ein festes Ziel weggelassen wird, kann auf dem entfernten SSH-Server ein SOCKS-Proxy erstellt werden.
• Die grundlegende Befehlsstruktur lautet wie folgt.

ssh -R [bind_address:]port [user@]gateway_addr  

• Der entfernte Gateway-Server wartet auf SOCKS-Verbindungen an dem angegebenen Port.
• Anfragen, die beim Proxy eingehen, werden durch den SSH-Tunnel an die Client-Seite weitergeleitet.
• Das endgültige Ziel wird aus der Netzperspektive des SSH-Clients erreicht.
• So kann ein entfernter Server auf das gesamte Heimnetz oder private Netz zugreifen, das vom PC des Benutzers aus erreichbar ist.
• Dynamisches entferntes Forwarding erfordert auf dem Client OpenSSH 7.6 oder höher.
• Soll der entfernte SOCKS-Proxy auf externen Schnittstellen veröffentlicht werden, ist wie beim normalen entfernten Forwarding ebenfalls die Einstellung GatewayPorts erforderlich.

Optionen für die Ausführung im Hintergrund halten nur den Tunnel aktiv

• Wenn nach dem SSH-Verbindungsaufbau kein Befehl ausgeführt werden soll und nur das Port-Forwarding aktiv bleiben soll, wird die Option -N verwendet.
• Mit der Option -f kann der Tunnel zusätzlich in den Hintergrund verschoben werden.
• Beispiele je nach Typ:

ssh -f -N -L ...  
ssh -f -N -R ...  
ssh -f -N -D ...  

• Für Automatisierung oder den Langzeitbetrieb sollten außerdem Strategien für Tunnel-Abbruch, Wiederverbindung und Störungserkennung vorgesehen werden.

Befehle werden danach unterschieden, wo der Port geöffnet wird

• ssh -L öffnet einen neuen Port auf dem lokalen SSH-Client.
• ssh -R öffnet einen neuen Port auf dem entfernten SSH-Server.
• ssh -D erstellt einen SOCKS-Proxy auf dem lokalen SSH-Client.
• ssh -R ohne Ziel erstellt einen SOCKS-Proxy auf dem entfernten SSH-Server.
• Die Grundregel zum Merken der Befehle lautet wie folgt.

-L = local:remote  
-R = remote:local  

• Adresse und Port links vom Doppelpunkt sind der neu geöffnete Listening-Endpunkt.
• local kann den SSH-Client selbst oder ein internes Gerät bezeichnen, das vom Client aus erreichbar ist.
• remote kann den SSH-Server selbst oder ein anderes internes Gerät bezeichnen, das vom Server aus erreichbar ist.

Fazit

SSH-Tunnel werden nach der Zugriffsrichtung gewählt

• Wenn ein entfernter Dienst auf dem eigenen PC genutzt werden soll, verwendet man lokales Forwarding mit -L.

• Wenn der eigene PC oder ein interner Dienst auf der Seite des entfernten Servers veröffentlicht werden soll, verwendet man entferntes Forwarding mit -R.

• Für flexiblen Zugriff auf mehrere Ziele im entfernten Netz verwendet man dynamisches lokales Forwarding mit -D.

• Wenn das gesamte clientseitige Netz vom entfernten Gateway aus flexibel erreichbar sein soll, verwendet man dynamisches entferntes Forwarding mit -R ohne Zielangabe.

• Beim Entwurf eines SSH-Tunnels sollten zuerst folgende Punkte geprüft werden:

  • Wo ein neuer Port geöffnet werden muss
  • Welches Gerät das endgültige Ziel erreichen kann
  • Einstellungen für GatewayPorts, Firewall und SSH-Zugriffsrechte
  • Sicherheitsrisiken, die durch eine externe Veröffentlichung entstehen können

• Das entscheidende Kriterium ist, auf welcher Seite der Dienst sichtbar sein soll und welches Gerät das Ziel tatsächlich erreichen kann.