termalAuf deinem Laptop läuft etwas – ein Dev-Server, eine API, eine Kiste zu Hause hinter NAT – und etwas auf der anderen Seite des Internets muss es erreichen. Keine öffentliche IP, kein Zugriff auf den Router, keine Zeit, ein VPN aufzusetzen. Genau dafür gibt es den SSH-Reverse-Tunnel, ssh -R: Er lässt einen Port auf einem Server erscheinen, den du erreichen kannst, und leitet alles, was dort ankommt, still zurück an deine Maschine.
Es ist das Flag, das den meisten verkehrt herum vorkommt – klären wir also zuerst das Denkmodell und arbeiten dann die echten Fälle durch.
Das Denkmodell: -L, gespiegelt
Jeder SSH-Tunnel öffnet einen lauschenden Port auf der einen Maschine und schickt alles, was dort ankommt, an einen Ort, der von der anderen Maschine aus erreichbar ist. Bei der lokalen Weiterleitung (-L) öffnet der Port auf deiner Maschine, und der Verkehr tritt auf der Serverseite aus. Ein Reverse-Tunnel ist das exakte Spiegelbild:
Mit -R öffnet der lauschende Port auf dem entfernten Server, und Verbindungen dorthin treten auf deiner Seite aus.
Das ist der ganze Trick. Die Maschine, die keine eingehenden Verbindungen annehmen kann, baut stattdessen eine ausgehende SSH-Verbindung auf – und lässt Verbindungen über sie zurück hereinkommen. Wenn beide noch verschwimmen, findest du das vollständige Familienporträt unter SSH-Portweiterleitung, erklärt.
Die Syntax, von links nach rechts gelesen
ssh -R [bind_address:]remote_port:localhost:local_port user@serverLies es so: Lausche auf dem Server auf remote_port; leite alles, was ankommt, an localhost:local_port weiter – aufgelöst von meiner Maschine aus. Also:
ssh -R 8080:localhost:3000 deploy@vps.example.comöffnet Port 8080 auf dem VPS, und jede Verbindung dorthin landet auf Port 3000 deines Laptops. Das Ziel muss nicht dein Laptop selbst sein – -R 8080:192.168.1.50:80 leitet an eine andere Maschine in deinem LAN weiter und nutzt deinen Laptop als Ausgang.
Ein Flag, das sich lohnt: -R 0:localhost:3000 lässt den Server einen beliebigen freien Port wählen und gibt Allocated port 43022 for remote forward aus, damit du weißt, welchen du bekommen hast.
Drei Dinge, die Leute tatsächlich damit bauen
Einem Kunden einen lokalen Dev-Server zeigen. Deine laufende Arbeit liegt auf localhost:3000. Statt sie nur für eine Demo irgendwo zu deployen:
ssh -N -R 8080:localhost:3000 deploy@demo.example.comJeder, der demo.example.com:8080 erreicht, sieht jetzt live die App auf deinem Laptop. (-N überspringt die Remote-Shell – du willst nur den Tunnel. Ob jeder oder nur der Server selbst verbinden kann, hängt von GatewayPorts ab – nächster Abschnitt.)
Eine Heim-Maschine hinter NAT erreichen. Deine Heim-Kiste kann keine Verbindungen annehmen, aber sie kann welche aufbauen. Lass sie einen Tunnel hinaus zu einem kleinen VPS halten:
# on the home machine
ssh -N -R 2222:localhost:22 tunnel@vps.example.comJetzt ist Port 2222 des VPS der SSH-Port der Heim-Maschine, und von überall:
ssh -J vps.example.com -p 2222 you@localhostspringt durch den VPS direkt in die Kiste hinter NAT. Das ist die klassische selbstgehostete Antwort auf SSH auf dein Heim-NAS oder deinen Server.
Webhooks an deinen Laptop ausliefern. Ein Zahlungsanbieter oder Git-Host muss an deinen in Entwicklung befindlichen Handler POSTen. Leite deren erreichbaren Endpoint zu dir zurück:
ssh -N -R 9000:localhost:9000 deploy@vps.example.comRichte den Webhook auf den VPS. Wenn du den Tunnel an das Loopback des Servers gebunden lässt (die Voreinstellung), setz nginx oder einen beliebigen Reverse-Proxy auf dem VPS vor 127.0.0.1:9000 – du bekommst TLS-Terminierung gratis und legst den rohen Tunnel-Port nie offen.
GatewayPorts: warum sonst niemand deinen Tunnel erreicht
Die Überraschung Nummer eins: Der Tunnel funktioniert, wenn du ihn vom Server aus testest (curl localhost:8080 klappt), aber niemand von außen kann verbinden. Das ist Absicht – standardmäßig bindet sshd remote-weitergeleitete Ports nur an 127.0.0.1, egal welche Bind-Adresse du angefordert hast.
Um einen Tunnel zur Welt zu öffnen, braucht die /etc/ssh/sshd_config des Servers:
GatewayPorts clientspecifieddann starte sshd neu und fordere die Bindung ausdrücklich an: ssh -R 0.0.0.0:8080:localhost:3000 .... (GatewayPorts yes bindet jede Remote-Weiterleitung an alle Schnittstellen, was breiter ist, als du meist willst.) Das ist eine serverseitige Entscheidung, die du vom Client aus nicht übergehen kannst – eine bewusste Sicherheitsvoreinstellung, denn ein Reverse-Tunnel ist ein von innen gebohrtes Loch, und was auch immer er freilegt, ist jetzt faktisch zum Internet hin gerichtet. Behandle es so.
Zwei verwandte serverseitige Schalter können dir in die Quere kommen: AllowTcpForwarding no deaktiviert Tunnel komplett, und PermitListen kann einschränken, welche Ports -R beanspruchen darf.
Am Leben halten
Ein Reverse-Tunnel ist eine einzige TCP-Verbindung, und untätige TCP-Verbindungen sterben. Für alles, was länger als eine Demo dauert:
ssh -N -R 2222:localhost:22 \
-o ServerAliveInterval=30 \
-o ExitOnForwardFailure=yes \
tunnel@vps.example.comServerAliveInterval 30hält Verkehr in Bewegung, damit NAT-Einträge und Idle-Timeouts die Verbindung nicht abräumen.ExitOnForwardFailure yeslässt ssh laut sterben, wenn der Remote-Port nicht gebunden werden kann, statt sich trotzdem zu verbinden und nichts weiterzuleiten.autosshumhüllt den Befehl und startet den Tunnel neu, sobald er abreißt – das Standardwerkzeug für Tunnel, die Reboots und wacklige Netze überstehen sollen, meist alsautossh -M 0 -N -R ...unter einer systemd-Unit.
Und sobald sich ein Tunnel einen festen Platz verdient, verschieb ihn mit einer RemoteForward-Zeile in die ~/.ssh/config, damit er mit dem Host-Eintrag mitreist – die Struktur behandelt der ssh_config-Leitfaden (auf Englisch):
Host homelink
HostName vps.example.com
User tunnel
RemoteForward 2222 localhost:22
ServerAliveInterval 30
ExitOnForwardFailure yes-L vs. -R vs. -D auf einen Blick
| Flag | Port öffnet auf | Verkehr tritt aus auf | Typische Aufgabe |
|---|---|---|---|
-L | deiner Maschine | Serverseite | eine entfernte DB/ein Dashboard auf localhost holen |
-R | dem Server | deiner Seite | lokalen Dienst bereitstellen; eine Kiste hinter NAT erreichen |
-D | deiner Maschine | Serverseite, beliebiges Ziel | SOCKS-Proxy in ein Netzwerk |
Wann ein Reverse-Tunnel das falsche Werkzeug ist
Ein Reverse-Tunnel ist eine hervorragende vorübergehende Antwort: Demos, Webhook-Debugging, das Retten einer Kiste hinter NAT. Als dauerhafte taugt er wenig. Wenn das, was du bereitstellst, monatelang laufen, echte Nutzer bedienen oder den Ruhezustand deines Laptops überstehen muss – dann ist das Ingress, und Ingress verdient echte Infrastruktur: einen Reverse-Proxy auf einem Server, ein VPN oder Overlay-Netzwerk, ein richtiges Deployment. Der Charme des Tunnels liegt darin, dass er ein Befehl ohne bleibenden Fußabdruck ist; in dem Moment, in dem du Monitoring dafür schreibst, bist du ihm entwachsen.
Die üblichen Fehler beheben
Warning: remote port forwarding failed for listen port 8080– der Port ist auf dem Server belegt. Oft ist der Übeltäter dein eigener vorheriger Tunnel: Der alte sshd-Prozess hält den Port, bis die tote Verbindung ihr Timeout erreicht. Keepalives verhindern den Zombie;-R 0:...umgeht die Kollision;ExitOnForwardFailuremacht aus der Warnung einen Fehler, den du nicht übersehen kannst.- Funktioniert vom Server, wird von außen abgelehnt – der Listener liegt auf dem Loopback des Servers. Das ist die
GatewayPorts-Voreinstellung, die ihre Arbeit tut; konfiguriere sie entweder, oder setz einen Reverse-Proxy vor den Port. - Der Tunnel verbindet, aber der Dienst antwortet nicht – prüf die lokale Hälfte: Lauscht überhaupt etwas auf dem lokalen Port, den du genannt hast?
-R 8080:localhost:3000ohne etwas auf deinem:3000liefert jedem Besucher ein connection refused. - Die SSH-Verbindung selbst kommt nicht zustande – das ist ein anderes Problem mit eigener Checkliste: Connection refused und timed out, entschlüsselt.
Wenn Tunnel zum Inventar werden
Den Reverse-Tunnel, den du einmal ausführst, tippst du. Der, der dein Homelab, deine Demo-Kiste und deinen Webhook-Endpoint trägt, ist Zustand, den du jeden Morgen nach jedem Ruhezustand des Laptops neu aufbaust – und bis Donnerstag aus den Augen verlierst. Termalins gespeicherter Tunnel-Manager hält lokale, remote und dynamische Weiterleitungen an dem Host, zu dem sie gehören: Starte sie mit einem Klick, sieh auf einen Blick, welche live sind, und lass sie sich mit der Verbindung neu aufbauen, statt sie aus der Shell-History abzutippen. Die Host-Liste – samt Schlüsseln, Jump-Hosts, Keepalives und Tunneln – synchronisiert sich Ende-zu-Ende-verschlüsselt über deine Maschinen. Und wenn eine Kiste dauerhaft hinter NAT sitzt, ersetzt ihr nur ausgehender Connector den handgemachten Reverse-Tunnel vollständig – kein eingehender Port und keine autossh-Unit zum Babysitten. Die Kommandozeile bringt dir bei, was -R bedeutet; ein Client sorgt dafür, dass die Tunnel, auf die du dich verlässt, nicht von deinem Gedächtnis abhängen.
Termalin ist ein kostenloser, plattformübergreifender SSH-Client mit integrierten Tunneln, SFTP und Schlüsselverwaltung – lade es herunter oder sieh, wie es deine Schlüssel sicher verwahrt.