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 (öffnet in neuem Tab) (englisch) mit Syntax-Hervorhebung passend zur Ausgabe (etwa Bash, PowerShell oder XML).

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 (nach 300 ms Pause), und beim Wechsel in einen Tab. Beim Öffnen der Seite steht schon ein Beispielbefehl für Local Forward im Editor.
• Über der Ausgabe sitzen Copy (in die Zwischenablage) und Download (als Datei, mit passendem Dateinamen wie local-forward.sh, local-forward.ps1 oder ssh-config).

Bei den vier Tunnel-Generatoren (Local, Remote, Dynamic, Jump Host) erscheint unter der Ausgabe zusätzlich eine Explanation-Tabelle, die jede erzeugte Flag (Spalte Flag) im Klartext erklärt (Spalte Meaning). Listen mit mehreren Weiterleitungen, Jump-Hosts oder Tunnel-Definitionen lassen sich über Add … erweitern und über das rote × wieder entfernen; die letzte Zeile bleibt stehen (At least one row is required.). Auf dem Smartphone werden diese Tabellen zu beschrifteten Blöcken untereinander.

Fast alle Generatoren prüfen deine Eingaben und zeigen am Fuß der Ausgabekarte eine Liste mit Warnhinweisen — der Befehl wird trotzdem erzeugt, du siehst aber, wo er hakt. Beispiele: ein Port außerhalb von 1 bis 65535, ein Hostname mit unzulässigen Zeichen, ein lokaler Port unter 1024 (braucht unter Linux/macOS Root-Rechte), eine Bind-Adresse außerhalb von Loopback, die den Port für andere Rechner öffnet, oder ForwardAgent in der SSH Config.

Das Tool speichert nichts. Nach einem Neuladen stehen wieder die Vorgabewerte in den Feldern.

Gemeinsame SSH-Optionen

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

• OS — Linux, macOS, Windows (OpenSSH), BSD oder WSL. Die Auswahl bestimmt das Ausgabeformat, siehe Ausgabe je Betriebssystem.
• SSH Host / SSH Port / SSH User — Ziel der Verbindung. Leere Felder ersetzt das Tool durch Platzhalter (server.example.com, user). Ein Port ungleich 22 fügt -p <port> hinzu; ein ungültiger Port erzeugt einen Warnhinweis, der Befehl nutzt dann 22.
• Identity File (optional) — der Pfad zum privaten Schlüssel; fügt -i <pfad> hinzu. Pfade mit Leerzeichen werden korrekt gequotet, ein führendes ~/ bleibt unquotiert, damit die Shell es expandiert. 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), führt keinen entfernten Befehl aus (-N, reiner Tunnel) und ergänzt -o ExitOnForwardFailure=yes: Lässt sich ein Port nicht binden, bricht ssh ab, statt ohne Weiterleitung weiterzulaufen. Unter Windows entfällt -f (siehe unten). Ohne diesen Schalter entsteht ein normaler Login mit Weiterleitung.
• 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.

Ausgabe je Betriebssystem

Für Linux, macOS, BSD und WSL gibt das Tool ein Bash-Skript aus: Shebang #!/usr/bin/env bash, ein erklärender Kommentar und der Befehl mit Zeilenfortsetzungen (\). Der Download endet auf .sh.

Für Windows (OpenSSH) entsteht ein PowerShell-Skript (.ps1) für das in Windows 10/11 mitgelieferte ssh.exe: Zeilenfortsetzung per Backtick, Quoting nach PowerShell-Regeln. Weil Windows-OpenSSH kein -f kennt, startet das Skript den Tunnel bei aktivem Background versteckt im Hintergrund:

$tunnel = Start-Process -WindowStyle Hidden -PassThru -FilePath ssh -ArgumentList @(
    '-L',
    '127.0.0.1:3306:127.0.0.1:3306',
    …
)
Write-Host "Tunnel running, PID $($tunnel.Id) - stop with: Stop-Process -Id $($tunnel.Id)"

Auf allen Systemen setzt das Tool IPv6-Adressen in Weiterleitungen automatisch in eckige Klammern (-L '[::1]:8080:[fd00::5]:80') — ohne sie meldet ssh „Bad forwarding specification“.

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, mindestens 1):

• autossh (recommended) — ersetzt ssh durch autossh -M 0 und setzt export AUTOSSH_GATETIME=0, damit autossh auch dann weiter versucht, wenn schon die erste Verbindung scheitert. Ein Kommentar nennt den Installationsbefehl für das gewählte OS (apt/dnf, brew, pkg). 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 — ist KeepAlive aus, warnt das Tool.
• while loop (no dependency) — umschließt den Befehl mit einer Schleife, die ssh nach jedem Ende nach <delay> Sekunden neu startet und den Abbruch mit Zeitstempel meldet. Dabei entfernt das Tool -f, weil die Schleife das Ende von ssh mitbekommen muss, und ergänzt -N sowie ExitOnForwardFailure=yes, falls sie fehlen. In Bash ist das while true; do … sleep <delay>; done (mit dem Hinweis, das Skript per nohup vom Terminal zu lösen), unter Windows while ($true) { … Start-Sleep -Seconds <delay> }.

Unter Windows gibt es kein autossh: Wählst du dort autossh, erzeugt das Tool automatisch die PowerShell-Schleife und sagt das im Hinweis.

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; ein leerer Bind lässt den Teil weg. Mehrere Zeilen (Add Port) ergeben mehrere -L-Flags in einem Aufruf. Der Remote Host wird aus Sicht des SSH-Servers aufgelöst — 127.0.0.1 ist also der Server selbst.

Warnhinweise gibt es für Ports außerhalb von 1 bis 65535, lokale Ports unter 1024 (außer unter Windows) und eine Bind-Adresse außerhalb von Loopback, die den Port für andere Rechner erreichbar macht.

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 (standardmäßig leer — Platzhalter server loopback), Remote Port (8080), Local Host (127.0.0.1) und Local Port (3000); daraus wird -R [bind:]rport:lhost:lport. Ohne Bind lauscht der Port nur auf der Loopback-Schnittstelle des Servers.

Soll der Port auf dem Server öffentlich erreichbar sein, hakst du Public on the server (GatewayPorts) an. Mit dem Schalter ergänzt das Tool einen Kommentarblock — auf dem Server muss in /etc/ssh/sshd_config GatewayPorts clientspecified stehen, danach sudo systemctl reload ssh (sshd auf RHEL/Fedora); der Port gehört hinter eine Firewall — und einen Warnhinweis, dass der Port auf allen Schnittstellen des Servers offen ist. Bleibt der Bind leer, setzt es zusätzlich 0.0.0.0 ein. Trägst du einen öffentlichen Bind ein, ohne den Schalter zu setzen, warnt das Tool, dass der Server ihn ignoriert und nur auf Loopback lauscht. Ein Remote Port unter 1024 funktioniert nur, wenn du dich als root am Server anmeldest — auch dazu gibt es einen Hinweis.

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. Ein Bind außerhalb von Loopback macht den Proxy zum offenen Proxy für alle, die deinen Rechner erreichen — das Tool warnt davor.

Am Ende der Ausgabe steht eine auskommentierte Testzeile, # curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me, mit der du prüfst, ob der Tunnel steht; --socks5-hostname lässt auch die DNS-Auflösung über den Server laufen. Ein Infokasten im Formular 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. Felder: OS, Mode, Identity File (optional) sowie die Schalter Compression -C und KeepAlive. In der Tabelle Jump Chain trägst du die Hops in Reihenfolge ein (Host, Port, User; Add Jump fügt nummerierte Zeilen an); darunter folgen Final Destination Host, Destination Port und Destination User.

Über Mode wählst du:

• Modern (-J / ProxyJump) — erzeugt ssh -J user@jump[:port],… plus optional -C, KeepAlive und -p für einen Ziel-Port ungleich 22. IPv6-Hops landen in eckigen Klammern. Erfordert OpenSSH 7.3 oder neuer. Ist ein Identity File gesetzt, stellt das Tool ssh-add <schlüssel> vor den Befehl: -i gilt bei -J nur für das Ziel, die Jump-Hosts holen sich den Schlüssel aus dem SSH-Agent. Unter Windows erinnert ein Hinweis daran, dass dafür der Dienst OpenSSH Authentication Agent laufen muss (Start-Service ssh-agent).
• Legacy (ProxyCommand) — bei genau einem Jump-Host ein Befehl mit -o 'ProxyCommand=ssh -W %h:%p … jumpuser@jumphost' (Port und Schlüssel des Jump-Hosts stecken im inneren ssh); bei mehreren Jumps gibt das Tool stattdessen verkettete ~/.ssh/config-Blöcke jump1 … jumpN und target aus, die du anschließend mit ssh target nutzt. Der Download heißt in diesem Fall ssh-config.

SSH Config (~/.ssh/config)

Erzeugt einen fertigen Host-Block zum Anhängen an ~/.ssh/config (unter Windows %USERPROFILE%\.ssh\config). Felder sind Host Alias (der Kurzname, mit dem du dich später per ssh <alias> verbindest; Leerzeichen ersetzt das Tool durch Bindestriche und warnt), HostName, Port (nur ungleich 22 im Block), User, optional IdentityFile und ProxyJump sowie ServerAliveInterval (60) und ServerAliveCountMax (3). Werte mit Leerzeichen werden in Anführungszeichen gesetzt.

Über Schalter werden Direktiven ergänzt:

• Compression → Compression yes
• ExitOnForwardFailure yes (standardmäßig an)
• Trust new host keys automatically → StrictHostKeyChecking accept-new: Ein unbekannter Server-Schlüssel wird beim ersten Kontakt gespeichert, ein geänderter Schlüssel aber weiterhin abgelehnt.
• ControlMaster auto — blendet ControlPath (Vorgabe ~/.ssh/sockets/%r@%h-%p) und ControlPersist (600) ein. Ein Kommentar über dem Block erinnert daran, das Socket-Verzeichnis anzulegen (mkdir -p ~/.ssh/sockets && chmod 700 ~/.ssh/sockets), und dass Windows-OpenSSH kein Connection Sharing unterstützt.
• AddKeysToAgent yes, IdentitiesOnly yes
• ForwardAgent yes (als security risk markiert) — die Ausgabe ergänzt eine Kommentarzeile, der Hinweis darunter erklärt, dass root auf dem Zielserver deine Schlüssel benutzen kann, solange du verbunden bist.

Die optionalen Felder ConnectTimeout und ConnectionAttempts landen nur im Block, wenn du eine Zahl einträgst.

Die Tabelle Port Forwards ist anfangs leer; mit Add Forward legst du Zeilen aus Type (Local/Remote/Dynamic), Bind:Port und Target:Port an. Daraus werden LocalForward, RemoteForward bzw. DynamicForward (Letzteres braucht nur Bind:Port). Zeilen ohne Bind:Port übergeht das Tool, bei LocalForward/RemoteForward ohne Ziel warnt es. Am Ende steht # Usage: ssh <alias> zusammen mit dem Prüfbefehl ssh -G <alias>, der zeigt, welche Werte ssh aus deiner Config tatsächlich übernimmt.

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).

Bei SOCKS5 schreibt das Tool Proxy-URLs als socks5h://host:port: Das h bedeutet, dass auch die Namensauflösung über den Tunnel läuft — interne Hostnamen funktionieren, DNS-Anfragen lecken nicht am Proxy vorbei. Das gilt für Shell-Variablen, git, npm, apt, dnf, pip und cargo. Go, Docker und kubectl bekommen socks5://, weil Go-Programme Hostnamen ohnehin an den SOCKS-Server schicken.

Unter NO_PROXY Exclusions legst du Ausnahmen fest: localhost / 127.0.0.1 (an; ergibt localhost,127.0.0.1,::1), Private ranges (als CIDR 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16), Link-local (169.254.0.0/16) sowie eigene Einträge im Textfeld, je Zeile oder durch Komma getrennt (z. B. .example.com). Für Java-Werkzeuge (Gradle, Maven) und die Windows-Bypass-Liste rechnet das Tool CIDR-Bereiche in Wildcards um, die diese Programme verstehen (10.*, 172.16.* … 172.31.*), und macht aus .example.com ein *.example.com.

Im Block Generate Configuration For hakst du an, wofür Konfigurationen erscheinen sollen — gruppiert in vier Karten:

• Shell & System
  • Shell env vars (an) — export von ALL_PROXY, HTTP_PROXY, HTTPS_PROXY (plus Kleinschreibung) und NO_PROXY für ~/.bashrc, ~/.zshrc oder ~/.profile, mit unset-Zeile zum Zurücksetzen.
  • macOS (networksetup) — SOCKS- bzw. Web-/Secure-Web-Proxy und Bypass-Domains für den Dienst "Wi-Fi" (mit Hinweis, wie du deinen Dienstnamen findest).
  • Windows (netsh / PowerShell) — Benutzer-Umgebungsvariablen per [Environment]::SetEnvironmentVariable(…, "User"); bei HTTP/HTTPS zusätzlich netsh winhttp set proxy mit Bypass-Liste für Systemdienste. WinHTTP kann kein SOCKS — bei SOCKS5 steht dort ein Hinweis.
  • Linux Desktop (gsettings) — GNOME-Systemproxy samt ignore-hosts und Reset-Befehl.
• Dev Tools
  • git — git config --global http.proxy plus Ausnahme für einzelne Server und --unset.
  • npm — proxy, https-proxy, noproxy und config delete.
  • Gradle / Android Studio — systemProp-Zeilen für ~/.gradle/gradle.properties (SOCKS oder HTTP/HTTPS, nonProxyHosts mit |) und den Menüpfad in Android Studio.
  • Maven — ein <proxy>-Block für ~/.m2/settings.xml; da Maven-Proxys nur HTTP können, gibt es für SOCKS stattdessen eine MAVEN_OPTS-Zeile.
• Package Managers
  • apt — Datei /etc/apt/apt.conf.d/95proxy per tee, mit Befehl zum Entfernen.
  • yum / dnf — proxy=-Zeile in /etc/dnf/dnf.conf (bzw. /etc/yum.conf), mit sed-Befehl zum Entfernen.
  • Docker — systemd-Drop-in /etc/systemd/system/docker.service.d/proxy.conf für den Daemon (Image-Pulls) samt daemon-reload und Neustart, dazu der JSON-Schnipsel für ~/.docker/config.json (Container und Builds). Bei SOCKS der Hinweis, dass 127.0.0.1 im Container der Container selbst ist.
  • curl / wget — Aufruf und ~/.curlrc-Zeile; wget kann kein SOCKS, dafür schlägt das Tool proxychains4 vor.
  • pip / poetry — pip install --proxy, pip.conf-Zeile, bei SOCKS der Hinweis auf PySocks.
  • Composer (PHP), cargo (Rust), go — passende Umgebungsvariablen (Composer: Prüfung mit composer diagnose; cargo: CARGO_HTTP_PROXY bzw. ~/.cargo/config.toml).
• Cloud CLIs
  • kubectl — HTTPS_PROXY/NO_PROXY und die Alternative proxy-url je Cluster in ~/.kube/config.
  • AWS CLI — Umgebungsvariablen; bei SOCKS der Hinweis, dass die AWS CLI kein SOCKS kann.
  • gcloud (GCP) — gcloud config set proxy/type|address|port samt unset.
  • Azure CLI — HTTPS_PROXY und ein Hinweis auf REQUESTS_CA_BUNDLE hinter TLS-inspizierenden Proxys.

Die Ausgabe reiht die gewählten Abschnitte mit Trennlinien aneinander; wo es einen klaren Weg zurück gibt, steht der Entfernen-Befehl gleich dabei. Ist nichts angehakt, steht dort nur # Select at least one section above.. Der Download heißt proxy-settings.sh.

Management Script

Erzeugt ein Verwaltungs-Skript für mehrere Tunnel. Felder: Script Type (Bash oder PowerShell), Script Name (tunnel-manager; Sonderzeichen werden ersetzt, er bestimmt auch den Download-Namen .sh/.ps1), PID Directory (/tmp/ssh-tunnels). Schalter: Auto-reconnect (an, blendet Reconnect Interval (seconds) ein — Vorgabe 30, mindestens 5), Logging (an, blendet Log Path ein — Vorgabe ~/.local/state/ssh-tunnels; für Pfade unter /var/log warnt das Tool beim Script Type Bash, dass dort meist nur root schreiben darf) und Health check.

In der Tabelle Tunnel Definitions beschreibst du jeden Tunnel mit Name, Type (Local/Remote/Dynamic), SSH Host, User, Port, Forward (für -L: [bind:]lokalerPort:zielHost:zielPort, für -R: [bind:]serverPort:lokalerHost:lokalerPort; für -D: nur der Port, leer 1080) und optionalem Key. Das Forward-Feld geht unverändert an ssh -L/-R/-D: Der Tooltip im Tool nennt für beide Richtungen localPort:remoteHost:remotePort, bei -R steht der erste Port aber für den Server. Doppelte Namen benennt das Tool um und meldet das; leere Felder füllt es mit Platzhaltern.

Jeder Tunnel startet als ssh -N mit festen Optionen: BatchMode=yes (nie auf eine Passwortabfrage warten — den Host-Key nimmst du vorher einmal von Hand an), ExitOnForwardFailure=yes und KeepAlive (60 s/3). Das Skript verwaltet je Tunnel eine PID-Datei.

• Bash (bash 3.2+, läuft also auch mit der macOS-Bash; Linux/macOS/BSD/WSL): Aufruf ./tunnel-manager.sh {start|stop|restart|status|list} [name] — den optionalen Namen werten start, stop, restart und status aus, ohne Namen wirken sie auf alle Tunnel; list, watch und health gelten immer für alle Tunnel. Mit Auto-reconnect kommt watch dazu (prüft alle Reconnect Interval Sekunden und startet ausgefallene Tunnel neu, Ende mit Strg+C), mit Health check health (prüft per nc -z, ob der lokale Port jedes Local-/Dynamic-Tunnels Verbindungen annimmt; Remote-Tunnel lauschen auf dem Server und werden übersprungen). start meldet nach einer Sekunde, ob der Tunnel wirklich läuft; mit Logging landet die Ausgabe je Tunnel in <Log Path>/<name>.log.
• PowerShell (5.1+, Windows OpenSSH): Aufruf .\tunnel-manager.ps1 start|stop|restart|status|list [-TunnelName name], mit Auto-reconnect zusätzlich watch; -TunnelName wirkt bei allen Aktionen außer list, das immer alle Tunnel zeigt. Tunnel laufen versteckt per Start-Process. Ein PID- oder Log-Pfad im Unix-Stil (beginnend mit /) wird unter $env:TEMP angelegt. Health check wirkt nur in der Bash-Variante.

Autostart Setup

Erzeugt eine Autostart-Konfiguration, die einen einzelnen Tunnel beim Booten bzw. bei der Anmeldung startet. Felder sind Autostart Method, SSH Host/Port/User, Identity File, Tunnel Type (Local/Remote/Dynamic), Forward Spec (leer gilt 3306:127.0.0.1:3306 — auch bei Dynamic; für -D trägst du den Port selbst ein, z. B. 1080), Service Name (ssh-tunnel), Run as User (leer, Beispiel alice; wirkt bei systemd und rc.d) und Description (SSH Tunnel Service).

Der zugrunde liegende Aufruf ist auf allen Systemen gleich aufgebaut: ssh -N -o BatchMode=yes -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -L <spec> [-p <port>] [-i <key>] user@host (statt -L je nach Tunnel Type -R oder -D). Weil Dienste ohne Terminal laufen, zeigt das Tool immer den Hinweis, den Host-Key einmal von Hand anzunehmen (ssh user@host) und einen Schlüssel ohne Passphrase oder einen Agent zu verwenden.

Die Ausgabe hat zwei Tabs: das Startskript tunnel.sh (exec ssh …; bei Task Scheduler entsteht stattdessen ein PowerShell-Skript, das als tunnel.ps1 heruntergeladen wird) und die Konfigurationsdatei, deren Tab-Beschriftung sich nach der gewählten Methode richtet. Copy und Download beziehen sich auf den gerade sichtbaren Tab. Über Autostart Method wählst du den Mechanismus:

• systemd (Linux) — <Service Name>.service mit Installationsanleitung in den Kommentaren (sudo cp …, daemon-reload, enable --now, journalctl -u … -f), After=/Wants=network-online.target, StartLimitIntervalSec=0, Restart=always und RestartSec=10. Ohne Run as User fehlt die Zeile User=; der Dienst liefe dann als root mit /root/.ssh — das Tool warnt.
• launchd (macOS) — com.user.<Service Name>.plist für ~/Library/LaunchAgents/ mit RunAtLoad, KeepAlive, ThrottleInterval 10 und Fehlerlog unter /tmp/<Service Name>.err; laden mit launchctl bootstrap gui/$(id -u) …, entladen mit launchctl bootout.
• Task Scheduler (Windows) — <Service Name>.xml mit Anmelde-Trigger, ohne Admin-Rechte, ohne Laufzeitlimit, auch im Akkubetrieb und mit Neustart bei Fehler (jede Minute, bis zu 999-mal); ausgeführt wird C:\Windows\System32\OpenSSH\ssh.exe. Der Download wird als UTF-16 mit BOM und Windows-Zeilenenden gespeichert, so wie es die XML-Deklaration verlangt; importieren mit schtasks /create /tn "<name>" /xml <name>.xml.
• rc.d (BSD) — ein rc-Skript, das ssh über daemon(8) startet und bei Abbruch neu startet (-r), mit Installationsbefehlen (install -m 755, sysrc <name>_enable=YES, service <name> start) und optionalem <name>_user.
• crontab @reboot (WSL/generic) — ein @reboot-Eintrag für crontab -e plus eine Variante für ~/.bashrc/~/.profile, die den Tunnel per nohup startet, wenn pgrep -f -- '-L <spec>' ihn nicht schon findet (WSL startet cron nicht von selbst).

Die Hilfe-Tabs

Troubleshooting

Ein Leitfaden zum Nachschlagen 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 und ein eigenes Modul für Quoting und Eingabeprüfung). 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 und werden nicht gespeichert.
• Keine Schlüssel im Tool: Du gibst nur den Pfad zu einer Identity-Datei an, nie den Schlüssel selbst.
• Quoting für jedes Zielformat: Dieselbe Eingabe wird je nach Ausgabe passend maskiert — für Bash, PowerShell, ssh_config, systemd-ExecStart, XML (launchd, Taskplaner) und Windows-Kommandozeilen. Ein Leerzeichen im Schlüsselpfad macht so keinen falschen Hostnamen mehr.
• 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.