JPKCom DB

SSH Proxy — Beispiele

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

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 mit einem Aufruf wie

ssh \
    -L 127.0.0.1:3306:127.0.0.1:3306 \
    -f \
    -N \
    -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 der Port lokal schon, kollidiert die Weiterleitung; 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 0.0.0.0, Remote Port 8080, Local Host 127.0.0.1, Local Port 3000.
  4. Den Schalter 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 — plus ein deutlicher Kommentarblock, der daran erinnert, dass der SSH-Server GatewayPorts clientspecified in /etc/ssh/sshd_config braucht und danach neu gestartet werden muss. Ohne diese Server-Einstellung bindet der Tunnel nur an 127.0.0.1 des Servers, nicht an 0.0.0.0.

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 -C … me@gateway.example.com, dazu fertige Test-Befehle wie curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me. Konfiguriere anschließend deine Anwendung auf den SOCKS5-Proxy 127.0.0.1:1080. Bequem geht das über den Proxy Settings-Generator (siehe Beispiel 6 weiter unten ist optional) — wichtig: in Firefox network.proxy.socks_remote_dns = true setzen, 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:

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

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. In der Forward-Tabelle: Type 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:

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

Danach reicht ssh meinserver, und die Weiterleitung steht automatisch. Mit Copy in die Zwischenablage, dann unten an deine Config anhängen.

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 Benutzername.
  5. Generate.

Ergebnis: zwei Tabs. tunnel.sh enthält das Start-Skript; db-tunnel.service enthält eine systemd-Unit mit Restart=always und RestartSec=10 samt eingebauter Installationsanleitung in den Kommentaren (sudo cp …, daemon-reload, enable --now). Den Service-Tab kopierst du nach /etc/systemd/system/db-tunnel.service 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.

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