JPKCom DB

SSH Proxy — Beispiele

SSH-Proxy-Durchläufe: Datenbank-Tunnel, Dev-Server exponieren, SOCKS-Proxy, Jump Host, ~/.ssh/config, systemd-Dienst, Windows und Tunnel-Skript.

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

Diese Seite zeigt SSH Proxy an konkreten Durchläufen. Hosts, Benutzer und Ports sind Beispiele — setze deine eigenen Werte ein. Wie die einzelnen Felder und Optionen genau arbeiten, steht im Manual. Denk daran: Das Tool baut nur die Befehle; ausgeführt werden sie in deinem eigenen Terminal.

Beispiel 1: Auf eine entfernte Datenbank zugreifen

Ziel: eine MySQL-Datenbank, die nur lokal auf dem Server lauscht, von deinem Rechner aus erreichen.

  1. Den Eintrag Local Forward wählen.
  2. SSH Host = db-server.example.com, SSH User = deploy, SSH Port = 22.
  3. In der Tabelle Port Forwards: Local Bind 127.0.0.1, Local Port 3306, Remote Host 127.0.0.1, Remote Port 3306.
  4. Background und KeepAlive an lassen, Generate klicken.

Ergebnis: ein Bash-Skript (OS = Linux) mit diesem Inhalt:

Terminal
#!/usr/bin/env bash
# Local port forwarding via SSH (-L local_bind:local_port:remote_host:remote_port)

ssh \
    -L 127.0.0.1:3306:127.0.0.1:3306 \
    -f \
    -N \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=60 \
    -o ServerAliveCountMax=3 \
    deploy@db-server.example.com

Nach dem Start verbindest du deinen DB-Client einfach mit 127.0.0.1:3306 — als liefe die Datenbank lokal. Die Erklärungs-Tabelle schlüsselt jede Flag auf. Läuft auf dem Port lokal schon etwas (etwa eine eigene MySQL-Instanz), bricht ssh dank ExitOnForwardFailure=yes mit einer Fehlermeldung ab, statt ohne Tunnel weiterzulaufen; wähle dann einen freien lokalen Port, etwa 13306.

Beispiel 2: Den lokalen Dev-Server nach außen geben

Ziel: deinen lokal laufenden Webserver (localhost:3000) für einen entfernten Server erreichbar machen, z. B. für einen Webhook-Test.

  1. Remote Forward wählen.
  2. SSH Host = public.example.com, SSH User = tunnel.
  3. Tabelle: Remote Bind leer lassen, Remote Port 8080, Local Host 127.0.0.1, Local Port 3000.
  4. Den Schalter Public on the server (GatewayPorts) anhaken (du willst, dass der Port von außen erreichbar ist).
  5. Generate.

Ergebnis: ein ssh -R 0.0.0.0:8080:127.0.0.1:3000-Aufruf — das Tool setzt 0.0.0.0 selbst ein — plus ein deutlicher Kommentarblock, der daran erinnert, dass der SSH-Server GatewayPorts clientspecified in /etc/ssh/sshd_config braucht und danach neu geladen werden muss (sudo systemctl reload ssh). Ohne diese Server-Einstellung bindet der Tunnel nur an die Loopback-Schnittstelle des Servers. Unter der Ausgabe erinnert ein Warnhinweis daran, dass der Port jetzt auf allen Schnittstellen des Servers offen ist — sichere ihn mit einer Firewall ab.

Reicht es, wenn nur Prozesse auf dem Server selbst deinen Dev-Server erreichen (etwa ein Webhook-Empfänger, der dort lokal weiterleitet), lässt du den Schalter aus: Dann entsteht -R 8080:127.0.0.1:3000, und der Port bleibt auf dem Server privat.

Beispiel 3: SOCKS5-Proxy zum Surfen über einen Server

Ziel: den Browser-Verkehr durch einen entfernten Server leiten.

  1. Dynamic / SOCKS wählen.
  2. SSH Host = gateway.example.com, SSH User = me.
  3. Bind Address 127.0.0.1, SOCKS Port 1080.
  4. Compression zusätzlich anhaken (langsame Leitung), Generate.

Ergebnis: ssh -D 127.0.0.1:1080 -f -N -o ExitOnForwardFailure=yes -C … me@gateway.example.com, darunter als Kommentar die Testzeile curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me — sie sollte die IP-Adresse des Gateways zeigen. Konfiguriere anschließend deine Anwendung auf den SOCKS5-Proxy 127.0.0.1:1080. Bequem geht das über den Proxy Settings-Generator: Proxy Type SOCKS5, Host 127.0.0.1, Port 1080, Abschnitt Shell env vars — die Variablen zeigen dann auf socks5h://127.0.0.1:1080, sodass auch die Namensauflösung durch den Tunnel läuft. Im Browser ist das eine eigene Einstellung: In Firefox setzt du network.proxy.socks_remote_dns = true, sonst lecken DNS-Anfragen am Proxy vorbei.

Beispiel 4: Über einen Bastion-Host ins interne Netz

Ziel: einen internen Server erreichen, der nur über einen Jump-Host zugänglich ist.

  1. Jump Host wählen, Mode = Modern (-J / ProxyJump).
  2. In der Tabelle Jump Chain: Host bastion.example.com, Port 22, User jumpuser.
  3. Final Destination Host = internal.example.com, Destination User = admin.
  4. Generate.

Ergebnis (KeepAlive ist vorangehakt):

Terminal
#!/usr/bin/env bash
# Multi-hop SSH via ProxyJump (-J, OpenSSH 7.3+)

ssh \
    -J jumpuser@bastion.example.com \
    -o ServerAliveInterval=60 \
    -o ServerAliveCountMax=3 \
    admin@internal.example.com

Trägst du zusätzlich ein Identity File ein, etwa ~/.ssh/id_ed25519, steht vor dem Befehl ssh-add ~/.ssh/id_ed25519: Ein -i gilt bei -J nur für das Ziel, der Bastion-Host bekommt den Schlüssel über den SSH-Agent. Brauchst du eine zweite Zwischenstation, klickst du Add Jump und ergänzt die Zeile — -J nimmt mehrere, durch Komma getrennte Hops auf. Auf sehr alten Servern (vor OpenSSH 7.3) wählst du stattdessen Legacy (ProxyCommand); bei mehreren Hops gibt das Tool dann verkettete ~/.ssh/config-Blöcke aus.

Beispiel 5: Einen wiederkehrenden Tunnel in ~/.ssh/config gießen

Ziel: nicht jedes Mal den langen Befehl tippen, sondern ssh meinserver genügen lassen.

  1. SSH Config wählen.
  2. Host Alias = meinserver, HostName = db-server.example.com, User = deploy.
  3. IdentityFile = ~/.ssh/id_ed25519.
  4. Unter Port Forwards auf Add Forward klicken (die Tabelle ist anfangs leer) und die Zeile füllen: Type Local (-L), Bind:Port 127.0.0.1:3306, Target:Port 127.0.0.1:3306.
  5. Generate.

Ergebnis: ein fertiger Block zum Anhängen an ~/.ssh/config:

# SSH config entry — append to ~/.ssh/config (Windows: %USERPROFILE%\.ssh\config)

Host meinserver
    HostName db-server.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3
    ExitOnForwardFailure yes
    LocalForward 127.0.0.1:3306 127.0.0.1:3306

# Usage: ssh meinserver   — check what ssh makes of it: ssh -G meinserver

Danach reicht ssh meinserver, und die Weiterleitung steht automatisch. Mit Copy in die Zwischenablage, dann unten an deine Config anhängen. Ob ssh den Block so liest wie gedacht, zeigt dir ssh -G meinserver: Der Befehl gibt die wirksame Konfiguration für diesen Alias aus, ohne eine Verbindung aufzubauen.

Beispiel 6: Einen Tunnel als systemd-Dienst beim Booten starten

Ziel: einen Datenbank-Tunnel dauerhaft als Dienst laufen lassen, der nach einem Neustart von selbst wieder hochkommt.

  1. Autostart Setup wählen, Autostart Method = systemd (Linux).
  2. SSH Host = db-server.example.com, SSH User = deploy, Identity File = ~/.ssh/id_ed25519.
  3. Tunnel Type = Local (-L), Forward Spec = 3306:127.0.0.1:3306.
  4. Service Name = db-tunnel, Run as User = dein lokaler Benutzername, etwa anna (bleibt das Feld leer, läuft der Dienst als root und sucht Schlüssel in /root/.ssh — das Tool warnt dann).
  5. Generate.

Ergebnis: zwei Tabs. tunnel.sh enthält das Start-Skript; db-tunnel.service enthält eine systemd-Unit, die auf network-online.target wartet, mit User=anna, Restart=always und RestartSec=10, samt eingebauter Installationsanleitung in den Kommentaren (sudo cp …, daemon-reload, enable --now, journalctl -u db-tunnel -f). Die ExecStart-Zeile ruft /usr/bin/ssh mit -o BatchMode=yes auf: Der Dienst fragt nie nach einem Passwort oder einer Bestätigung. Melde dich deshalb vorher einmal als anna von Hand per ssh deploy@db-server.example.com an, um den Host-Key anzunehmen, und nutze einen Schlüssel ohne Passphrase oder einen Agent — darauf weist auch der Hinweis unter der Ausgabe hin.

Den Service-Tab speicherst du per Download (der Dateiname db-tunnel.service passt schon), kopierst ihn nach /etc/systemd/system/ und aktivierst ihn — der Tunnel überlebt dann Neustarts und Abbrüche. Brauchst du mehrere Tunnel zentral verwaltet, ist stattdessen der Management Script-Generator die bessere Wahl (siehe Beispiel 8).

Beispiel 7: Denselben Tunnel unter Windows starten

Ziel: den Datenbank-Tunnel aus Beispiel 1 auf einem Windows-Rechner mit dem eingebauten OpenSSH-Client betreiben.

  1. Local Forward wählen, OS = Windows (OpenSSH).
  2. SSH Host = db-server.example.com, SSH User = deploy, Identity File = C:\Users\anna\.ssh\id_ed25519.
  3. Port-Weiterleitung wie in Beispiel 1, Background und KeepAlive an lassen, Generate.

Ergebnis: ein PowerShell-Skript. Weil Windows-OpenSSH kein -f kennt, startet es ssh versteckt im Hintergrund und nennt dir die Prozess-ID zum Beenden:

Terminal
# Local port forwarding via SSH (-L local_bind:local_port:remote_host:remote_port)
# PowerShell — Windows 10/11 ships OpenSSH (ssh.exe)

# Windows OpenSSH has no -f: Start-Process runs ssh hidden in the background
$tunnel = Start-Process -WindowStyle Hidden -PassThru -FilePath ssh -ArgumentList @(
    '-L',
    '127.0.0.1:3306:127.0.0.1:3306',
    '-i',
    'C:\Users\anna\.ssh\id_ed25519',
    '-N',
    '-o',
    'ExitOnForwardFailure=yes',
    '-o',
    'ServerAliveInterval=60',
    '-o',
    'ServerAliveCountMax=3',
    'deploy@db-server.example.com'
)
Write-Host "Tunnel running, PID $($tunnel.Id) - stop with: Stop-Process -Id $($tunnel.Id)"

Download speichert das Skript als local-forward.ps1. Hakst du zusätzlich Auto-Reconnect an, bleibt es auch mit autossh bei Windows-Bordmitteln: Das Tool erzeugt eine while ($true) { … }-Schleife, die ssh nach jedem Abbruch nach Retry Delay Sekunden neu startet, und erklärt im Hinweis, warum. Soll der Tunnel bei jeder Anmeldung starten, nimm Autostart Setup mit Task Scheduler (Windows) — die XML-Datei importierst du mit schtasks /create /tn "ssh-tunnel" /xml ssh-tunnel.xml.

Beispiel 8: Mehrere Tunnel mit einem Skript verwalten und überwachen

Ziel: zwei Tunnel — die Datenbank und einen SOCKS-Proxy — mit einem Befehl starten, prüfen und bei Ausfall neu starten.

  1. Management Script wählen, Script Type = Bash, Script Name = tunnels.
  2. Auto-reconnect und Logging an lassen, Health check anhaken.
  3. Erste Zeile der Tunnel Definitions: Name db, Type Local (-L), SSH Host db-server.example.com, User deploy, Forward 3306:127.0.0.1:3306.
  4. Add Tunnel, zweite Zeile: Name socks, Type Dynamic (-D), SSH Host gateway.example.com, User me, Forward 1080.
  5. Download — die Datei heißt tunnels.sh.

Ergebnis: ein Skript, das auch mit der älteren Bash 3.2 auf macOS läuft:

Terminal
chmod +x tunnels.sh
./tunnels.sh start          # beide Tunnel starten
./tunnels.sh status         # [up]/[down] je Tunnel
./tunnels.sh health         # nimmt Port 3306 bzw. 1080 lokal Verbindungen an?
./tunnels.sh restart db     # nur einen Tunnel neu starten
./tunnels.sh watch          # alle 30 s prüfen und Ausgefallene neu starten

Jeder Tunnel läuft mit BatchMode=yes — nimm die Host-Keys also vorher einmal per Hand an. Die Logs landen je Tunnel unter ~/.local/state/ssh-tunnels/<name>.log; startet ein Tunnel nicht, sagt dir start das nach einer Sekunde und verweist auf diese Datei. Für Windows wählst du PowerShell und rufst das Skript als .\tunnels.ps1 start bzw. .\tunnels.ps1 restart -TunnelName db auf; health gibt es dort nicht.

Mehr zu den einzelnen Generatoren steht im Manual, strategische Hinweise und Stolperfallen in den Tipps & Tricks. Direkt loslegen kannst du im Tool.