# SSH Proxy — Tipps & Tricks > Strategie und Stolperfallen für SSH Proxy: Bind-Adressen, GatewayPorts, DNS-Leaks bei SOCKS, KeepAlive vs. autossh, Agent-Forwarding und Tunnel-Alternativen. Source: https://www.jpkc.com/db/tools/ssh-proxy/tips/ Zurück zur Übersicht: [SSH Proxy](https://www.jpkc.com/db/tools/ssh-proxy/) · Tool live öffnen: [www.jpkc.com/tools/ssh-proxy/](https://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](https://www.jpkc.com/db/tools/ssh-proxy/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](https://www.jpkc.com/db/tools/ip/)** — Bind-Adressen, Netze und private Bereiche prüfen, bevor du sie in eine Weiterleitung oder NO_PROXY-Liste einträgst. - **[DNS, SSL, Redirect & URL](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/)** — checken, ob der Ziel-Host überhaupt auflöst und erreichbar ist, bevor du den Tunnel debuggst. - **[Passwort- & Schlüssel-Generator](https://www.jpkc.com/db/tools/generator/)** — starke Passwörter für Dienste, die am anderen Ende des Tunnels hängen. --- Die vollständige Funktionsbeschreibung steht im [Manual](https://www.jpkc.com/db/tools/ssh-proxy/manual/), konkrete Durchläufe in den [Beispielen](https://www.jpkc.com/db/tools/ssh-proxy/examples/). Ausprobieren kannst du alles im [Tool](https://www.jpkc.com/tools/ssh-proxy/).