Visueller Leitfaden für SSH-Tunneling und Port Forwarding (2023)

Visueller Leitfaden für SSH-Tunneling und Port Forwarding

• Zusammenfassung: Dieser Blogbeitrag wurde verfasst, um das Verständnis von SSH-Tunneling und Port Forwarding zu erleichtern. Die Themen umfassen Anwendungsfälle, Einrichtung, SSH-Jump-Hosts, lokales/Remote-/dynamisches Port Forwarding sowie Einschränkungen.

Anwendungsfälle

• Sicherheit:

  • Verschlüsselung unsicherer Verbindungen wie FTP
  • Zugriff auf Web-Admin-Panels über SSH-Tunnel (Authentifizierung per öffentlichem Schlüssel)
  • Reduzierung der Anzahl exponierter Ports (nur Port 22 ist offen)

• Fehlerbehebung:

  • Umgehung von Firewalls/Inhaltsfiltern
  • Auswahl eines anderen Pfads

• Verbindung:

  • Zugriff auf Server hinter NAT
  • Zugriff auf interne Server über das Internet mithilfe eines Jump-Hosts
  • Lokale Ports im Internet verfügbar machen

Port Forwarding

• Einrichtung/Vorbereitung:
  • Lokale und entfernte Benutzer benötigen Berechtigungen, um Ports zu öffnen
  • Für Ports 0–1024 sind Root-Rechte erforderlich
  • Client- und Netzwerk-Firewalls müssen passend konfiguriert sein
  • Port Forwarding muss auf dem SSH-Server aktiviert sein: AllowTcpForwarding yes
  • Um Ports auf andere Interfaces weiterzuleiten, muss GatewayPorts yes aktiviert sein

SSH-Jump-Host / SSH-Tunnel

• Verbindung über einen Jump-Host:

  ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1
  

• Verwendung mehrerer Jump-Hosts:

  ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1
  

Lokales Port Forwarding

• Beispiel 1:

  ssh -L 10.10.10.1:8001:localhost:8000 user@REMOTE-MACHINE
  

• Beispiel 2:

  ssh -L 8001:10.99.99.1:8000 user@REMOTE-MACHINE
  

Remote Port Forwarding

• Beispiel 1+2:

  ssh -R 8000:localhost:8001 user@REMOTE-MACHINE
  ssh -R 8000:10.10.10.2:8001 user@REMOTE-MACHINE
  

• Beispiel 3:

  ssh -R 10.99.99.2:8000:10.10.10.2:8001 user@REMOTE-MACHINE
  

Dynamisches Port Forwarding

• Verwendung des SOCKS-Protokolls:

  ssh -D 10.10.10.1:5555 user@REMOTE-MACHINE
  

SSH-TUN/TAP-Tunneling

• Erstellung eines bidirektionalen TCP-Tunnels:

  ssh -w local_tun[:remote_tun]
  

SSH im Hintergrund ausführen

• Im Hintergrund ausführen:

  ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE
  

• Hintergrund-SSH beenden:

  ps -ef | grep ssh
  kill <PID>
  

SSH-Verbindung aufrechterhalten

• Timeout-Behandlung:
  • ClientAliveInterval 15
  • ClientAliveCountMax 3

Einschränkungen

• UDP:

  • SSH unterstützt kein UDP, da es eine zuverlässige Übertragung erfordert

• TCP-over-TCP:

  • Durch erhöhten Overhead sinkt der Durchsatz und die Latenz steigt

• Kein Ersatz für VPN:

  • SSH-Tunneling kann ein VPN ersetzen, aber in Bezug auf die Performance ist ein VPN besser geeignet

• Potenzielle Sicherheitsrisiken:

  • Es ist ratsam, nicht benötigte Funktionen zu deaktivieren

Zusammenfassung von GN⁺

• Dieser Artikel erklärt verschiedene Anwendungsfälle und Einrichtungsmethoden für SSH-Tunneling und Port Forwarding
• SSH-Tunneling ist nützlich, um sichere Verbindungen bereitzustellen und Firewalls zu umgehen
• Es ist jedoch kein vollständiger Ersatz für ein VPN und hat Einschränkungen wie Performance-Verluste
• Zu den verwandten Projekten gehören VPN-Lösungen wie OpenVPN

[GN⁺]

Hacker-News-Kommentare

• Im Jahr 2024 ist es besser, statt SSH-Befehle direkt zu schreiben die Datei ~/.ssh/config zu verwenden, um LocalForward, RemoteForward und ProxyJump zu konfigurieren

  • Mit einer Beispielkonfiguration kann man Zeit sparen, wenn man Daten über mehrere zwischengeschaltete SSH-Verbindungen überträgt
  • Nach der Konfiguration kann man per Alias SSH, SCP und RSYNC für target-server verwenden
  • Mit den Einstellungen für LocalForward und RemoteForward lässt sich Port Forwarding einfach umsetzen

• SSH-Tunneling ist in komplexen Unternehmensumgebungen unverzichtbar

  • Wegen viel Bürokratie und langer Wartezeiten dauert es, die nötigen Zugriffsrechte zu bekommen
  • Verwendet man den Befehl ssh -D 8888 someserver und setzt den SOCKS-Proxy des Browsers auf localhost:8888, wird der Browser-Traffic über diesen Server geroutet

• Wenn man sich per SSH mit einem Linux-Server oder IoT-Gerät hinter einer Firewall ohne feste IP verbinden möchte, kann man einen Tunneling-Dienst nutzen

  • Beispiel: sshreach.me

• Die komplexeste SSH-Tunneling-Bastelei entstand bei einer Verbindung zwischen Rechenzentren

  • Daten mussten von A nach B und von B nach C bewegt werden
  • Durch die Kombination von rsync, SSH-Tunneln, Schlüsseln und Routing konnten die Daten erfolgreich übertragen werden
  • Damals war das ein großer Erfolg, und die Erinnerung daran ist bis heute lebendig

• Es wäre wünschenswert, wenn Netzwerkvisualisierung häufiger eingesetzt würde

  • Besonders bei Traffic-Visualisierung auf niedriger Verbindungsebene besteht Bedarf

• TCP-over-TCP kann den Overhead erhöhen und die Latenz vergrößern, was die Leistung verschlechtern kann

  • Bei SSH-Tunneln ist das normalerweise kein Problem, sofern nicht TAP/TUN verwendet wird
  • Wenn jedoch mehrere Kanäle genutzt werden, kann es zu Leistungseinbußen kommen

• SSH-Tunnel sind großartige Werkzeuge, aber heutzutage werden häufiger Tools mit eingebautem TLS und Reverse-Proxy-Funktionen verwendet

  • Liste verwandter Tools: awesome-tunneling

• sshuttle ist ein besseres Werkzeug für Tunneling

  • Mit dem Befehl sshuttle -r user@host 10.0.0.0/8 kann es wie ein VPN genutzt werden

• Vor 15 Jahren wurde begonnen, SSH-Tunnel zu nutzen, um die Firewall des Universitätsnetzwerks zu umgehen

  • Dafür wurde der Standardport auf 443 geändert
  • Seitdem wird es nicht nur zur Umgehung von Firewalls, sondern auch für viele andere Zwecke verwendet

• Es wird gefragt, ob SSH selbst eine Redirect-Funktion hat

  • Wenn A versucht, sich per SSH mit B zu verbinden, weist B A an, sich mit C zu verbinden, und A verbindet sich dann transparent direkt mit C
  • B ist dann nicht länger Teil des kritischen Datenpfads
  • Es wird gefragt, ob es eine solche Funktion gibt