Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

SSH-Tunnel: Portweiterleitung über SSH¶

Ein SSH-Tunnel leitet TCP-Verbindungen durch eine bestehende, verschlüsselte SSH-Verbindung weiter. Für die getunnelte Anwendung sieht es aus, als käme die Verbindung ganz normal von localhost — tatsächlich läuft sie verschlüsselt über SSH zu einem entfernten Rechner. Damit lassen sich Dienste erreichen, die nicht öffentlich freigegeben sind, ohne eine eigene VPN-Infrastruktur zu betreiben.

Funktionsprinzip¶

Das SSH-Protokoll überträgt mehrere logische Channels über eine einzige TCP-Verbindung (üblicherweise Port 22). Ein Channel trägt die interaktive Shell-Sitzung, ein anderer kann eine reine Portweiterleitung sein. Die weitergeleiteten Daten selbst brauchen kein eigenes Verschlüsselungsprotokoll — SSH übernimmt das für den gesamten Kanal.

Die drei Varianten¶

Local Forwarding (-L)¶

ssh -L LOKALER_PORT:ZIEL_HOST:ZIEL_PORT user@ssh-server

Öffnet einen Port auf dem eigenen Rechner. Verbindungen dorthin werden über den SSH-Server zu ZIEL_HOST:ZIEL_PORT weitergeleitet. ZIEL_HOST muss nicht der SSH-Server selbst sein — er muss nur von dort aus erreichbar sein.

# Admin-Oberfläche, die nur auf localhost:3000 des Servers lauscht
ssh -L 3000:127.0.0.1:3000 admin@server.example.org

# Datenbank auf einem internen Host hinter dem SSH-Server erreichen
ssh -L 5432:db-internal.example.org:5432 admin@server.example.org

Typische Einsatzzwecke: Admin-Oberflächen, Datenbank-Clients, interne Dashboards, einmalige Ersteinrichtungen (siehe Wiki.js: Ersteinrichtung auf einem Headless-Server).

Remote Forwarding (-R)¶

ssh -R REMOTE_PORT:ZIEL_HOST:ZIEL_PORT user@ssh-server

Öffnet einen Port auf dem entfernten Server. Verbindungen dorthin werden zurück zum lokalen Rechner (oder einem von dort erreichbaren Ziel) geleitet.

# lokalen Entwicklungsserver kurzzeitig über einen öffentlichen Server erreichbar machen
ssh -R 8080:127.0.0.1:3000 user@public-server.example.org

Typischer Einsatz: ein Rechner hinter NAT oder Firewall ohne eingehende Verbindungen (z. B. ein Raspberry Pi im Heimnetz) baut selbst eine ausgehende SSH-Verbindung zu einem öffentlichen Server auf und macht sich darüber von außen erreichbar.

Dynamic Forwarding (-D)¶

ssh -D 1080 user@ssh-server

Öffnet lokal einen SOCKS5-Proxy. Anwendungen, die SOCKS unterstützen (Browser, curl --socks5), können darüber beliebige Ziele ansprechen, die vom SSH-Server aus erreichbar sind — das Ziel wird zur Laufzeit von der Anwendung bestimmt, nicht beim Tunnelaufbau. Faktisch ein Mini-VPN für einzelne Programme.

curl --socks5 localhost:1080 http://internal-service.example.org/

Tunnel zu Unix-Sockets¶

SSH kann Verbindungen nicht nur zu TCP-Ports, sondern auch zu Unix-Domain-Sockets weiterleiten — auf beiden Seiten des Tunnels:

# lokalen TCP-Port zu einem Unix-Socket auf dem Server weiterleiten
ssh -L 8080:/var/lib/tomcat10/xwiki-socket/xwiki.sock user@server

# lokalen Unix-Socket zu einem entfernten TCP-Ziel weiterleiten
ssh -L /tmp/local.sock:127.0.0.1:5432 user@server

Das ist unter anderem nützlich, um einen Dienst, der absichtlich nur über einen Unix-Socket lauscht — etwa nach den Anleitungen XWiki über Unix-Socket anbinden oder Wiki.js über Unix-Socket anbinden — für eine Wartungssitzung testweise ohne Nginx direkt zu erreichen.

Nützliche Optionen¶

Reiner Hintergrund-Tunnel ohne Shell:

ssh -N -f -o ExitOnForwardFailure=yes -L 5432:localhost:5432 user@server

Dauerhafte Tunnel¶

Ein per Hand gestarteter Tunnel bricht bei Netzwerkunterbrechungen ab. Für dauerhafte Verbindungen eignet sich autossh, das die SSH-Verbindung bei Abbruch automatisch neu aufbaut:

sudo apt install autossh
autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -L 5432:localhost:5432 user@server

-M 0 deaktiviert den klassischen autossh-Monitor-Port und verlässt sich stattdessen auf die SSH-eigenen Keepalive-Optionen — das ist die heute übliche Empfehlung, da der Monitor-Port selbst einen zusätzlichen offenen Port bedeuten würde.

Für einen dauerhaft laufenden Tunnel als Systemdienst eignet sich ein eigener systemd-Service, siehe systemd-Dienste erstellen.

Kurzform per SSH-Config¶

Häufig genutzte Tunnel lassen sich in ~/.ssh/config als Alias hinterlegen:

Host db-tunnel
    HostName server.example.org
    User admin
    LocalForward 5432 localhost:5432
    ServerAliveInterval 60

Danach genügt:

ssh -N db-tunnel

Absicherung auf dem Server¶

Auf dem SSH-Server (/etc/ssh/sshd_config) lässt sich steuern, ob und wie Tunnel überhaupt erlaubt sind:

sudo nano /etc/ssh/sshd_config
sudo systemctl reload sshd

Fehlerbehandlung¶

bind: Address already in use¶

Der lokale Port ist bereits belegt — durch einen alten Tunnel oder eine andere Anwendung.

sudo ss -ltnp | grep PORT

channel N: open failed: administratively prohibited¶

Der Server erlaubt keine Portweiterleitung für diesen Nutzer oder generell (AllowTcpForwarding no). Serverseitige sshd_config prüfen.

channel N: open failed: connect failed¶

Der SSH-Server konnte das eigentliche Ziel (ZIEL_HOST:ZIEL_PORT) nicht erreichen — Zieladresse, Zielport oder Netzwerkroute vom Server aus prüfen, nicht vom eigenen Rechner aus.

Tunnel scheint zu stehen, reagiert aber nicht mehr¶

Meist eine tote TCP-Verbindung ohne Keepalive. Mit ServerAliveInterval/ServerAliveCountMax arbeiten (siehe oben) oder auf autossh umsteigen.

Wichtige Befehle im Überblick¶

Verwandte Themen¶

• UFW-Firewall installieren und steuern
• systemd-Dienste erstellen
• XWiki über Unix-Socket anbinden
• Wiki.js über Unix-Socket anbinden
• Wiki.js nativ unter Linux installieren

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).