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), passe Hosts und Ports an und teste in einer sicheren Umgebung, bevor du etwas produktiv schaltest. 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.
Remote Forward schlägt 0.0.0.0 vor. Das macht den Port auf dem Server öffentlich — und greift nur, wenn der Server GatewayPorts clientspecified gesetzt hat. Ohne diese Einstellung bindet SSH still an 127.0.0.1 des Servers, 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).

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 generiert das Tool in den Test-Befehlen.
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; auf Windows nicht nativ verfügbar — dort WSL oder die Schleife nehmen).
Die while-Schleife kommt ohne Zusatzsoftware aus, hat aber keine Health-Checks. Beachte: Das Tool entfernt dabei -f, weil die Schleife den Tunnel im Vordergrund halten muss.

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. Aktivierst du Health check, prüft es zusätzlich, ob die Ports wirklich lauschen. Soll alles beim Booten hochkommen, kombiniere es mit Autostart Setup (systemd Restart=always ist hier robuster als ein @reboot-Cron).

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. Genauso gehört StrictHostKeyChecking no nicht in die Produktion; es ist im Tool nicht ohne Grund mit (insecure) gekennzeichnet.

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.

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 — für UDP oder roaming-feste interaktive Sitzungen ist z. B. mosh die bessere Wahl.

Kombination mit anderen JPKCom-Tools

IP-Tool — 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.
Passwort- & Schlüssel-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.