SSH-Tunnel: Dienste erreichen, ohne sie ins Internet zu stellen

SSH ist mehr als eine Shell auf einem fernen Rechner. Die verschlüsselte Verbindung kann auch beliebige TCP-Verbindungen durchreichen – ein Tunnel. Damit lassen sich Admin-Oberflächen nutzen, die von außen gar nicht erreichbar sind.

Das Problem

Die Weboberfläche eines Servers (Virtualisierung, Datenbank-Verwaltung, Proxy-Admin) soll nur der Administrator sehen. Steht sie offen im Internet, wird sie automatisch gefunden und mit Passwörtern angegriffen. Besser: Der Port bleibt zu, und man geht durch den SSH-Tunnel hinein.

Local Forward (-L): der Standardfall

ssh -N -L 8006:127.0.0.1:8006 admin@server.example.org

Danach im Browser https://localhost:8006 öffnen. Die drei Teile von -L:

Wichtig ist der zweite Teil: „127.0.0.1“ heißt hier nicht dein Rechner, sondern der Server. So erreicht man auch Rechner hinter dem Server, die selbst keine öffentliche Adresse haben:

ssh -N -L 8081:10.0.0.20:8081 admin@server.example.org   # Container im internen Netz

-N startet keine Shell, die Verbindung dient nur dem Tunnel. Mit -f läuft er im Hintergrund.

Bequem: ~/.ssh/config

Host server1
    HostName 203.0.113.10
    User admin
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30
    ServerAliveCountMax 4
    LocalForward 8006 127.0.0.1:8006
    LocalForward 8081 10.0.0.20:8081

Ab jetzt reicht ssh -N server1. ServerAliveInterval sendet regelmäßig ein Lebenszeichen, damit ein Router den ruhigen Tunnel nicht abbaut.

Weitere Tunnelarten

• Sprungserver (-J / ProxyJump): ssh -J admin@bastion.example.org admin@10.0.0.20 – erst zum Server mit öffentlicher Adresse, von dort weiter ins interne Netz.
• Dynamic Forward (-D): ssh -N -D 1080 admin@server.example.org macht den Server zum SOCKS-Proxy (siehe unten).
• Remote Forward (-R): ssh -R 9000:localhost:3000 admin@server.example.org – ein lokaler Dienst wird auf dem Server erreichbar. Nützlich zum Testen, aber sicherheitlich heikel: Man macht selbst eine Tür auf.

Und die IP verbergen?

Hier wird oft etwas vermischt. Ein SSH-Tunnel verbirgt je nach Richtung etwas anderes:

Test für den SOCKS-Fall:

ssh -N -D 1080 admin@server.example.org
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me   # zeigt die IP des Servers

Im Browser (z. B. Firefox) unter Netzwerkeinstellungen: SOCKS-Host 127.0.0.1, Port 1080, SOCKS v5, und „Proxy-DNS bei Verwendung von SOCKS v5“ aktivieren. Sonst gehen die Namensanfragen an dir vorbei durchs normale Netz.

Prüfen und Fehler finden

ss -tlnp | grep 8006                  # lauscht der lokale Port?
curl -k https://127.0.0.1:8006        # antwortet das Ziel? (-k: selbstsigniertes Zertifikat)
ssh -v -N server1                     # ausführliche Ausgabe, wenn etwas hakt

• „bind: Address already in use“: Der lokale Port ist belegt (alter Tunnel läuft noch). Anderen Port wählen oder den alten Prozess beenden.
• „channel open failed: administratively prohibited“: Der Server verbietet Weiterleitungen. Prüfen, ob AllowTcpForwarding no gesetzt ist.
• Zertifikatswarnung im Browser: Bei selbstsignierten Zertifikaten normal, denn der Name localhost passt nicht zum Zertifikat.
• Der Tunnel bindet standardmäßig nur an 127.0.0.1. Andere Rechner im WLAN können ihn nicht mitbenutzen (das ändert erst -L 0.0.0.0:… oder die Option -g).

Auf dem Server absichern

Beim Härten von SSH sollte AllowTcpForwarding yes bleiben, sonst funktioniert kein Tunnel. Wer genauer sein will, erlaubt nur bestimmte Ziele:

# /etc/ssh/sshd_config.d/20-tunnel.conf
AllowTcpForwarding yes
PermitOpen 127.0.0.1:8006 10.0.0.20:8081

Wenn der Tunnel dauerhaft laufen soll

Für Dauerbetrieb eignen sich autossh oder ein systemd-Dienst mit Restart=always. Im Alltag reicht meist ssh -N server1 in einem Terminal. Für mehrere Nutzer oder viele Dienste ist ein VPN wie WireGuard bequemer.