SSH Proxy — Manual

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

Dieses Manual beschreibt SSH Proxy vollständig: wie die Oberfläche aufgebaut ist, was jeder der zehn Generatoren tut, welche Optionen es gibt und was real erzeugt wird. Die Oberfläche des Tools ist auf Englisch — die Labels werden hier in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Aufbau und Bedienung

Links steht eine Navigationsleiste mit zehn Einträgen, gruppiert in Port Forwarding, Configuration, Scripts & Automation und Help. Rechts erscheint zum gewählten Eintrag eine Karte mit Eingabefeldern und darunter das Ausgabefeld — ein schreibgeschützter ACE-Editor (englisch) mit Syntax-Hervorhebung.

Drei Wege führen zur Ausgabe:

Der Generate-Knopf oben rechts in der Eingabekarte erzeugt das Ergebnis und scrollt zur Ausgabe.
Das Tool generiert außerdem automatisch neu, sobald du ein Feld änderst (leicht verzögert).
Über der Ausgabe sitzen Copy (in die Zwischenablage) und Download (als Datei, mit passendem Dateinamen wie local-forward.sh oder ssh-config).

Bei den Tunnel-Generatoren erscheint zusätzlich eine Explanation-Tabelle, die jede erzeugte Flag (linke Spalte) im Klartext erklärt (rechte Spalte). Listen mit mehreren Weiterleitungen, Jump-Hosts oder Tunnel-Definitionen lassen sich über Add … erweitern und über das rote × wieder entfernen (mindestens eine Zeile bleibt erhalten).

Gemeinsame SSH-Optionen

Die drei reinen Tunnel-Generatoren (Local/Remote/Dynamic) teilen einen Satz Felder und Schalter. Wie sie sich auf den Befehl auswirken:

SSH Host / SSH Port / SSH User — Ziel der Verbindung. Ein Port ungleich 22 fügt -p <port> hinzu; der Benutzer ergibt das user@host-Ziel.
Identity File (optional) — der Pfad zum privaten Schlüssel; fügt -i <pfad> hinzu. Es wird nur der Pfad eingetragen, nie der Schlüssel selbst.
Background -f -N (standardmäßig an) — schickt SSH nach der Anmeldung in den Hintergrund (-f) und führt keinen entfernten Befehl aus (-N, reiner Tunnel).
Compression -C — schaltet Kompression ein (nützlich auf langsamen Leitungen).
KeepAlive (60s) (standardmäßig an) — ergänzt -o ServerAliveInterval=60 -o ServerAliveCountMax=3, damit abgerissene Verbindungen erkannt werden.
OS — ein Auswahlfeld (Linux, macOS, Windows (OpenSSH), BSD, WSL). Der erzeugte ssh-Aufruf für eine Weiterleitung nutzt Standard-OpenSSH-Syntax und ist auf allen genannten Systemen gleich; das Feld dient hier vor allem der Einordnung.

Der fertige Befehl wird als Bash-Skript mit Shebang und erklärenden Kommentaren ausgegeben, die Flags über Zeilenfortsetzungen (\) umgebrochen.

Auto-Reconnect

Alle drei Tunnel-Generatoren haben einen Schalter Auto-Reconnect. Ist er aktiv, erscheinen zwei Zusatzfelder — Reconnect Method und Retry Delay (s) (Vorgabe 5):

autossh (recommended) — ersetzt ssh durch autossh -M 0 und setzt die Umgebungsvariablen AUTOSSH_GATETIME=0 und AUTOSSH_PIDFILE. autossh ist ein eigenes Programm (nicht Teil von OpenSSH), das die Verbindung überwacht und bei Abbruch neu aufbaut; -M 0 deaktiviert den alten Monitoring-Port und verlässt sich stattdessen auf die KeepAlive-Optionen.
while loop (no dependency) — umschließt den Befehl mit einer while true; … sleep <delay>; done-Schleife und entfernt dabei das -f (Hintergrund), weil die Schleife den Tunnel im Vordergrund halten muss, um Abbrüche zu erkennen.

Die Generatoren im Detail

Local Forward (`ssh -L`)

Leitet einen Port auf deiner lokalen Maschine durch den SSH-Server an einen entfernten Dienst. Typischer Fall: Zugriff auf eine Datenbank oder einen Webdienst hinter einer Firewall.

In der Tabelle Port Forwards definierst du je Zeile eine Weiterleitung mit Local Bind (Vorgabe 127.0.0.1), Local Port (Vorgabe 3306), Remote Host (127.0.0.1) und Remote Port (3306). Daraus wird je Zeile -L bind:lport:rhost:rport. Mehrere Zeilen ergeben mehrere -L-Flags in einem Aufruf.

Remote Forward (`ssh -R`)

Macht einen lokalen Dienst auf dem entfernten Server verfügbar (umgekehrte Richtung). Typischer Fall: einem entfernten Server Zugriff auf deine lokale Entwicklungsumgebung geben oder Webhooks testen.

Die Tabelle hat Remote Bind (Vorgabe 0.0.0.0), Remote Port (8080), Local Host (127.0.0.1) und Local Port (3000); daraus wird -R bind:rport:lhost:lport. Zusätzlich gibt es den Schalter GatewayPorts. Ist er an, ergänzt das Tool einen Kommentarblock mit dem Hinweis, dass der SSH-Server dafür GatewayPorts clientspecified in sshd_config setzen und sshd neu starten muss — sonst akzeptiert der entfernte Port keine externen Verbindungen.

Dynamic / SOCKS (`ssh -D`)

Baut einen SOCKS5-Proxy-Tunnel. Aller Verkehr, den eine Anwendung über diesen Proxy schickt, tritt am SSH-Server aus — wie ein leichtgewichtiges VPN. Felder: Bind Address (Vorgabe 127.0.0.1) und SOCKS Port (1080); daraus wird -D bind:port.

Die Ausgabe ergänzt zu den gewohnten Kommentaren auch Test-Befehle, z. B. curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me, mit denen du prüfst, ob der Tunnel steht. Ein Hinweis verweist auf den Proxy Settings-Generator, um Anwendungen auf den Proxy umzustellen.

Jump Host (`ssh -J`)

Verbindet über einen oder mehrere Bastion-/Jump-Hosts auf ein Ziel. Über das Feld Mode wählst du:

Modern (-J / ProxyJump) — erzeugt ssh -J user@jump[:port],… plus optional -i, -C, KeepAlive und -p für einen Ziel-Port ungleich 22. Erfordert OpenSSH 7.3 oder neuer.
Legacy (ProxyCommand) — bei genau einem Jump-Host ein Befehl mit -o "ProxyCommand=ssh -W %h:%p … jumpuser@jumphost"; bei mehreren Jumps gibt das Tool stattdessen verkettete ~/.ssh/config-Blöcke aus, weil sich Mehrfach-Hops so sauberer abbilden lassen.

In der Tabelle Jump Chain trägst du die Hops in Reihenfolge ein (Host, Port, User); darunter folgen Final Destination Host, Destination Port und Destination User.

SSH Config (`~/.ssh/config`)

Erzeugt einen fertigen Host-Block zum Anhängen an ~/.ssh/config. Pflichtfelder sind Host Alias (der Kurzname, mit dem du dich später per ssh <alias> verbindest), HostName, Port, User. Optional: IdentityFile, ProxyJump, ServerAliveInterval (60) und ServerAliveCountMax (3).

Über Schalter werden Direktiven ergänzt: Compression, ExitOnForwardFailure yes (an), StrictHostKeyChecking no (als unsicher markiert), ControlMaster auto, AddKeysToAgent yes, IdentitiesOnly yes und ForwardAgent yes (als Sicherheitsrisiko markiert — die Ausgabe ergänzt dann eine Warnung). Aktivierst du ControlMaster, erscheinen ControlPath (Vorgabe ~/.ssh/sockets/%r@%h-%p) und ControlPersist (600). Optionale Felder ConnectTimeout und ConnectionAttempts runden den Block ab.

Eine eigene Tabelle erzeugt aus Type (L/R/D), Bind:Port und Target:Port die Direktiven LocalForward, RemoteForward bzw. DynamicForward. Am Ende steht ein # Usage: ssh <alias>-Hinweis.

Proxy Settings

Erzeugt Konfigurations-Befehle, um deine Werkzeuge auf einen Proxy umzustellen — typischerweise nach dem Aufbau eines SOCKS-Tunnels mit ssh -D. Oben wählst du Proxy Type (SOCKS5/HTTP/HTTPS), Proxy Host (127.0.0.1) und Proxy Port (1080).

Unter NO_PROXY Exclusions legst du Ausnahmen fest: localhost / 127.0.0.1 (an), private Bereiche (10.*, 172.16–31.*, 192.168.*), Link-local (169.254.*) sowie eigene Einträge im Textfeld. Im Block Generate Configuration For hakst du an, wofür Konfigurationen erscheinen sollen — gruppiert in vier Karten:

Shell & System — Shell-Umgebungsvariablen (an), macOS (networksetup), Windows (netsh / PowerShell), Linux-Desktop (gsettings).
Dev Tools — git, npm, Gradle / Android Studio, Maven.
Package Managers — apt, yum / dnf, Docker, curl / wget, pip / poetry, Composer (PHP), cargo (Rust), go.
Cloud CLIs — kubectl, AWS CLI, gcloud (GCP), Azure CLI.

Die Ausgabe reiht die gewählten Abschnitte aneinander, jeweils mit Setz- und Entfernen-Befehlen. Das Tool berücksichtigt dabei den Proxy-Typ — etwa weist es darauf hin, dass netsh und wget SOCKS nicht nativ unterstützen, und schlägt Alternativen vor.

Management Script

Erzeugt ein produktionsreifes Verwaltungs-Skript für deine Tunnel mit den Aktionen start / stop / status / restart / list (optional zusätzlich reconnect und health). Felder: Script Type (Bash oder PowerShell), Script Name (tunnel-manager), PID Directory (/tmp/ssh-tunnels). Schalter: Auto-reconnect (an, blendet Reconnect Interval = 30s ein), Logging (an, blendet Log Path = /var/log/ssh-tunnels ein) und Health check.

In der Tabelle Tunnel Definitions beschreibst du jeden Tunnel mit Name, Type (L/R/D), SSH Host, User, Port, Forward (für -L/-R: localPort:remoteHost:remotePort; für -D: nur der Port) und optionalem Key. Das Skript verwaltet PID-Dateien, baut für jeden Tunnel einen ssh -N …-Befehl mit festen KeepAlive- und ExitOnForwardFailure-Optionen und prüft beim Health-Check, ob der jeweilige Port lauscht. Die Bash-Variante nutzt ein assoziatives Array, die PowerShell-Variante eine Hashtable.

Autostart Setup

Erzeugt eine Autostart-Konfiguration, die deinen Tunnel beim Booten startet. Über Autostart Method wählst du den Mechanismus:

systemd (Linux) — eine .service-Unit mit Restart=always und RestartSec=10.
launchd (macOS) — eine .plist mit RunAtLoad und KeepAlive.
Task Scheduler (Windows) — eine .xml mit Logon-Trigger und Neustart bei Fehler.
rc.d (BSD) — ein rc-Skript über daemon.
crontab @reboot (WSL/generic) — ein @reboot-Eintrag plus eine ~/.bashrc/~/.profile-Variante mit pgrep-Prüfung.

Felder sind SSH Host/Port/User, Identity File, Tunnel Type (L/R/D), Forward Spec, Service Name (ssh-tunnel), Run as User ($USER) und Description. Die Ausgabe hat zwei Tabs: tunnel.sh (das Start-Skript) und die OS-spezifische Konfigurationsdatei, deren Tab-Beschriftung sich nach der gewählten Methode richtet (z. B. ssh-tunnel.service). Der zugrunde liegende ssh -N …-Befehl trägt fest die KeepAlive- und ExitOnForwardFailure-Optionen.

Die Hilfe-Tabs

Troubleshooting

Ein durchsuchbarer Leitfaden für elf typische SSH-Probleme als Aufklapp-Liste — von Connection refused, Permission denied (publickey), Port already in use und Host key verification failed über Broken pipe, Channel open failed und SOCKS proxy not working bis zu autossh, SSH-Agent-Problemen, DNS durch SOCKS und Reconnect-Strategien bei Netzwechsel.

Oben rechts wählst du das OS (Linux/macOS/Windows/BSD/WSL); zu jedem Problem zeigt das Tool dann die passenden Diagnose-Befehle (jeweils mit eigenem Copy-Knopf) und eine Liste konkreter Lösungen. Dieser Tab generiert nichts, er stellt fertiges Wissen dar.

Reference

Eine Sammlung von Nachschlage-Tafeln, ebenfalls ohne Generierung: eine Vergleichstabelle der Forward-Typen (-L/-R/-D/-J), Datenfluss-Diagramme für jeden Typ, eine Tabelle gängiger SSH-Flags, Do/Don't-Sicherheitslisten, Beispiel-Szenarien, eine Anleitung zur Schlüssel-Erzeugung (Ed25519 vs. RSA mit Vergleichstabelle), ein Abschnitt zu Connection Multiplexing (ControlMaster) und ein Vergleich SSH-Tunnel vs. Alternativen (WireGuard, ngrok / Cloudflare Tunnel, AWS SSM, Teleport, Tailscale / ZeroTier).

Architektur und Grenzen

Rein clientseitig: SSH Proxy ist reines JavaScript (jQuery, ACE-Editor). Es gibt kein Server-Backend, kein API und keinen SSH-Verbindungsaufbau — das Tool erzeugt ausschließlich Text. Deine Eingaben (Hosts, Benutzer, Pfade) verlassen den Browser nicht.
Keine Schlüssel im Tool: Du gibst nur den Pfad zu einer Identity-Datei an, nie den Schlüssel selbst.
Ausführen liegt bei dir: Befehle und Skripte sind ein Ausgangspunkt. Prüfe und teste sie in einer sicheren Umgebung, bevor du sie produktiv einsetzt — falsch konfigurierte Tunnel können interne Dienste exponieren. Darauf weist auch der Disclaimer am Seitenende hin.

Für den Einstieg und die Zielgruppen siehe die Übersichtsseite. Konkrete Durchläufe stehen in den Beispielen, Strategie und Stolperfallen in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.