SSH Proxy — Tipps & Tricks

Zurück zur Übersicht: SSH Proxy · Tool live öffnen: www.jpkc.com/tools/ssh-proxy/

SSH Proxy nimmt dir die Flag-Reihenfolge ab — die strategischen Entscheidungen bleiben aber bei dir. Diese Seite sammelt, worauf es in der Praxis ankommt. Die technischen Grundlagen dazu stehen im Manual.

Das Tool baut nur — gelesen und geprüft wird von dir

SSH Proxy stellt keine Verbindung her und führt nichts aus. Es erzeugt Text. Behandle jede Ausgabe als Vorlage: lies sie durch (die Explanation-Tabelle hilft dabei), achte auf die gelben Warnhinweise unter der Ausgabe, passe Hosts und Ports an und teste in einer sicheren Umgebung, bevor du etwas produktiv schaltest. Die Hinweise blockieren nichts — der Befehl wird trotzdem erzeugt —, aber sie zeigen genau die Stellen, an denen ein Tunnel später scheitert oder mehr öffnet als gedacht. Der Disclaimer am Seitenende sagt es deutlich — falsch konfigurierte Tunnel können interne Dienste exponieren.

Bind-Adresse: `127.0.0.1` vs. `0.0.0.0`

Die wichtigste Sicherheitsentscheidung steckt im Bind:

Local Forward bindet standardmäßig an 127.0.0.1 — der weitergeleitete Port ist nur von deiner Maschine aus erreichbar. Lass das so, außer du brauchst bewusst Zugriff aus dem LAN; eine Bind-Adresse außerhalb von Loopback (etwa 0.0.0.0 oder eine LAN-IP) quittiert das Tool mit einem Warnhinweis.
Remote Forward lässt den Bind standardmäßig leer — der Port lauscht dann nur auf der Loopback-Schnittstelle des Servers. Öffentlich wird er erst mit dem Schalter Public on the server (GatewayPorts), der 0.0.0.0 einsetzt. Das greift aber nur, wenn der Server GatewayPorts clientspecified gesetzt hat; ohne diese Einstellung bindet SSH still an Loopback, egal was du angibst. Erwartest du externen Zugriff und bekommst keinen, ist fast immer die fehlende Server-Einstellung schuld (siehe Troubleshooting-Tab, Channel open failed).
Dynamic / SOCKS gehört ebenfalls auf 127.0.0.1. Ein SOCKS-Port auf einer öffentlichen Adresse ist ein offener Proxy für alle, die deinen Rechner erreichen — auch davor warnt das Tool.

SOCKS5: DNS-Leaks vermeiden

Ein häufiger Stolperstein bei ssh -D: Der Tunnel steht, aber DNS-Anfragen gehen weiter über deinen lokalen Resolver — die Gegenseite sieht dann zwar deinen Proxy-Verkehr, aber dein Provider sieht, welche Domains du auflöst.

Beim Testen mit curl --socks5-hostname (nicht --socks5) nehmen — dann löst der SOCKS-Server den Namen auf. Genau diese Variante schreibt das Tool in die Testzeile unter dem ssh -D-Befehl.
Für Kommandozeilen-Werkzeuge erledigt das der Proxy Settings-Generator: Bei Proxy Type SOCKS5 schreibt er die Proxy-URLs als socks5h://… — das h schickt auch die Namensauflösung durch den Tunnel, sodass sogar interne Hostnamen hinter dem Server auflösbar werden.
In Firefox network.proxy.socks_remote_dns = true setzen.
Der Troubleshooting-Tab (DNS resolution not going through SOCKS proxy) liefert OS-spezifische Diagnose-Befehle dazu.

KeepAlive lassen, für Dauerbetrieb autossh

Die KeepAlive-Optionen (ServerAliveInterval=60, ServerAliveCountMax=3) sind nicht ohne Grund vorangehakt: Ohne sie merkt SSH einen toten Tunnel oft erst sehr spät. Lass sie an.

Für Tunnel, die immer stehen sollen, reicht KeepAlive allein nicht — es erkennt den Abbruch nur, baut aber nicht neu auf. Dafür ist Auto-Reconnect da:

autossh ist der robustere Weg, braucht aber das gleichnamige Programm (apt install autossh, brew install autossh, pkg install autossh — den passenden Befehl schreibt das Tool als Kommentar dazu). Unter Windows gibt es autossh nicht; wählst du dort Windows (OpenSSH) als OS, erzeugt das Tool automatisch eine PowerShell-Schleife.
Die Wiederholungsschleife kommt ohne Zusatzsoftware aus, hat aber keine Health-Checks. Beachte: Das Tool entfernt dabei -f, weil die Schleife das Ende von ssh mitbekommen muss, und setzt ExitOnForwardFailure=yes — sonst liefe ein ssh ohne Weiterleitung einfach weiter, und die Schleife würde nie neu starten. Unter Linux und macOS startest du so ein Skript mit nohup ./skript.sh >/dev/null 2>&1 &, damit es das Abmelden überlebt.

autossh mit -M 0 verlässt sich vollständig auf die KeepAlive-Optionen, um einen toten Tunnel zu erkennen. Schaltest du KeepAlive ab, weist dich das Tool darauf hin — lass beides zusammen an.

Mehrere Tunnel? Skript statt Handarbeit

Sobald du mehr als einen oder zwei Tunnel jonglierst, lohnt der Management Script-Generator: ein Skript mit start/stop/status/restart/list und PID-Verwaltung schlägt das händische Starten und Suchen per ps deutlich — start, stop, restart und status nehmen optional einen Tunnelnamen, sodass du auch einen einzelnen Tunnel neu startest. Mit Auto-reconnect kommt watch dazu, das ausgefallene Tunnel im eingestellten Intervall neu startet; mit Health check prüft health (in der Bash-Variante), ob die lokalen Ports wirklich Verbindungen annehmen. Soll alles beim Booten hochkommen, kombiniere es mit Autostart Setup (systemd Restart=always ist hier robuster als ein @reboot-Cron). Den Log-Pfad lässt du am besten auf der Vorgabe ~/.local/state/ssh-tunnels — unter /var/log darf ein normaler Benutzer meist nicht schreiben.

Dienste fragen nicht nach: Host-Key und Schlüssel vorbereiten

Alles, was ohne Terminal läuft — die Autostart Setup-Dienste und die Tunnel des Management Script —, startet ssh mit BatchMode=yes. Das ist Absicht: Ein Dienst, der auf eine Passwortabfrage oder die Frage „Are you sure you want to continue connecting?“ wartet, hängt sonst unsichtbar fest. Die Kehrseite: Du musst vorher zwei Dinge erledigen.

Host-Key einmal von Hand annehmen — als genau der Benutzer, unter dem der Dienst läuft: ssh deploy@db-server.example.com, Fingerprint prüfen, bestätigen.
Schlüssel ohne Passphrase oder einen Agent verwenden.

Bei systemd gehört außerdem Run as User ausgefüllt — sonst läuft der Tunnel als root und sucht Host-Keys und Schlüssel in /root/.ssh.

ForwardAgent ist ein Risiko — ProxyJump ist die Antwort

In der SSH Config ist ForwardAgent yes bewusst als Sicherheitsrisiko markiert: Wer Root auf dem Zielhost hat, kann über deinen weitergereichten Agenten deine Schlüssel benutzen. Brauchst du eigentlich nur einen Sprung über einen Bastion-Host, nimm stattdessen ProxyJump (-J) — das tunnelt die Verbindung durch, ohne den Agenten preiszugeben. Den Schlüssel für die Hops liefert dabei dein lokaler Agent; deshalb setzt der Jump-Host-Generator bei einem Identity File ein ssh-add vor den Befehl.

Ähnlich bei Host-Keys: StrictHostKeyChecking no gehört nicht in die Produktion, weil es auch einen geänderten Server-Schlüssel klaglos akzeptiert. Der Schalter Trust new host keys automatically in der SSH Config setzt deshalb StrictHostKeyChecking accept-new: Neue Hosts werden beim ersten Kontakt gespeichert, ein später geänderter Schlüssel aber weiterhin abgelehnt — der Komfort ohne die Lücke.

ControlMaster für viele schnelle Verbindungen

Wenn Werkzeuge wie Ansible, rsync oder git viele SSH-Verbindungen hintereinander zum selben Host öffnen, spart Connection Multiplexing spürbar Zeit: Die erste Verbindung wird zum „Master", weitere teilen sie sich. In der SSH Config aktivierst du das über ControlMaster auto plus ControlPath/ControlPersist. Der Reference-Tab erklärt die Verwaltungsbefehle (ssh -O check/exit) — und denk dran, das Socket-Verzeichnis vorher anzulegen: mkdir -p ~/.ssh/sockets && chmod 700 ~/.ssh/sockets. Den Befehl schreibt das Tool auch als Kommentar über den Block. Unter Windows bringt das nichts: Der OpenSSH-Client dort unterstützt kein Connection Sharing.

Wann ein SSH-Tunnel das falsche Werkzeug ist

SSH-Tunnel sind ideal für schnellen, punktuellen Zugriff auf einen einzelnen Dienst über einen vorhandenen SSH-Server. Für anderes gibt es bessere Mittel — der Reference-Tab vergleicht sie: WireGuard für vollen Netzwerkzugang, ngrok / Cloudflare Tunnel für öffentlich erreichbare Endpunkte ohne eigenen Server, Teleport für Zero-Trust-Zugriff mit Audit-Trail, Tailscale / ZeroTier für ein Mesh über viele Geräte. SSH-Tunnel sind außerdem nur TCP — wer UDP braucht, nimmt ein VPN wie WireGuard; für roaming-feste interaktive Sitzungen ist mosh die bessere Wahl.

Kombination mit anderen JPKCom-Tools

IP Tools — Bind-Adressen, Netze und private Bereiche prüfen, bevor du sie in eine Weiterleitung oder NO_PROXY-Liste einträgst.
DNS, SSL, Redirect & URL — checken, ob der Ziel-Host überhaupt auflöst und erreichbar ist, bevor du den Tunnel debuggst.
Generator — starke Passwörter für Dienste, die am anderen Ende des Tunnels hängen.

Die vollständige Funktionsbeschreibung steht im Manual, konkrete Durchläufe in den Beispielen. Ausprobieren kannst du alles im Tool.