SSH-Tunnel: lokale, entfernte und dynamische Portweiterleitung

Worum es geht

Die ssh(1)-Manpage beschreibt drei Weiterleitungsmodi. -L [bind_address:]port:host:hostport lauscht auf einem lokalen Port und leitet jede Verbindung über den gesicherten Kanal an host:hostport weiter, wie sie von der entfernten Maschine aus erreicht wird (lokale Weiterleitung). -R [bind_address:]port:host:hostport lauscht auf dem entfernten Host und leitet Verbindungen zurück an ein vom Client aus erreichbares Ziel (entfernte Weiterleitung); wird nur ein Port angegeben, agiert der Client als SOCKS-Proxy für die entfernte Seite. -D [bind_address:]port öffnet einen lokalen SOCKS4/5-Proxy, dessen Ziel pro Verbindung entschieden wird (dynamische Weiterleitung). -J destination verbindet zunächst über einen Jump Host, eine Abkürzung für ProxyJump. -N führt keinen entfernten Befehl aus, was laut Manpage nützlich ist, um nur Ports weiterzuleiten. Auch Unix-Sockets lassen sich weiterleiten. Die lauschende Seite bindet gemäss GatewayPorts; eine bind_address von localhost hält den Port lokal, während * ihn auf allen Schnittstellen öffnet.

Warum es wichtig ist

Tunnel erreichen Datenbanken, Admin-Oberflächen und interne APIs, die absichtlich nicht offengelegt sind, ohne Firewall-Ports zu öffnen, mit denselben Schlüsseln und Protokollen wie eine interaktive SSH-Sitzung. Derselbe Mechanismus macht aus einem unachtsam gebundenen Tunnel einen Weg, einen internen Dienst im Netz zu veröffentlichen.

So wird es angewendet

• Eine Datenbank in einem privaten Netz erreichen: ssh -N -L 5433:db.internal:5432 bastion, dann mit localhost:5433 verbinden.
• Einen lokalen Entwicklungsserver einer entfernten Maschine zeigen: ssh -N -R 8080:localhost:3000 host. Auf dem Server entscheidet GatewayPorts in sshd_config, ob andere Hosts sich mit diesem Port verbinden dürfen; standardmässig werden entfernte Weiterleitungen an Loopback gebunden.
• Durch das entfernte Netz surfen: ssh -N -D 1080 host und den Client auf den SOCKS-Proxy richten.
• Über eine Bastion springen: ssh -J bastion target, oder ProxyJump in ~/.ssh/config; Weiterleitungen dort als LocalForward und RemoteForward halten, damit sie reproduzierbar sind.
• ExitOnForwardFailure yes setzen, damit ssh sich beendet, wenn eine angeforderte Weiterleitung nicht gebunden werden kann, statt ohne sie fortzufahren; ServerAliveInterval ergänzen, damit eine tote Verbindung bemerkt wird.
• Auf Servern AllowTcpForwarding (no, local oder remote) für Konten einschränken, die keine Weiterleitung brauchen.

Stolpersteine

Eine Weiterleitung, die "funktioniert", kann einem älteren, noch laufenden ssh-Prozess gehören, der den Port weiterhin belegt; Lauscher mit ss -ltnp prüfen. Nur die Superuserin kann privilegierte Ports weiterleiten. -R öffnet nicht die entfernte Firewall. ExitOnForwardFailure deckt nur die Einrichtung des Lauschers ab, nicht Fehlschläge beim Erreichen des eigentlichen Ziels. Tunnel umgehen Netzwerkrichtlinien per Konstruktion, deshalb jeden dauerhaften dokumentieren.