Was ist ~/.ssh/config und warum lohnt es sich?
Verbindest du dich mit mehr als einem Server, tippst du wahrscheinlich immer wieder `ssh -i ~/.ssh/work_key -p 2222 deploy@10.0.0.20`. Eine einzige Datei `~/.ssh/config` macht aus all dem `ssh prod`.
Dieser Builder schreibt die Datei für dich. Preset wählen (Production-Server, Bastion-Jump, GitHub, SOCKS-Proxy, Dev-Container...), Felder anpassen, und das rechte Panel zeigt den exakten Text zum Pasten in `~/.ssh/config`. Jede Option hat einen Plain-Hint, du musst nicht auswendig lernen, welche Großbuchstaben OpenSSH will.
Alles läuft im Browser: keine Keys beteiligt, nichts hochgeladen, kein Account. Der Output ist nackte OpenSSH-Config, identisch zu dem, was du von Hand schreiben würdest.
So nutzt du das Tool
- Starte mit einem Preset (Production-Server, Bastion, GitHub, SOCKS-Proxy...). Das Formular füllt sinnvolle Defaults, die du anpassen kannst.
- Tipp das Host-Alias (Kurzname, den du nach `ssh` tippst), dann den HostName (echte Adresse oder IP), User und Port, falls nicht 22.
- Identity öffnen und IdentityFile auf deinen Private-Key zeigen, z. B. `~/.ssh/id_ed25519`. IdentitiesOnly anschalten, damit SSH nicht jeden Key aus deinem Agent durchprobiert.
- Brauchst du einen Jump-Host? Proxy / Jump öffnen und `user@bastion` in ProxyJump eintragen. SSH connectet automatisch durch die Bastion.
- Für Port-Forwarding Forwarding öffnen und Zeilen wie `8080 localhost:80` in LocalForward (Remote-Port lokal exposen) oder RemoteForward (lokalen Service auf dem Server exposen) hinzufügen.
- Copy im Preview klicken, in `~/.ssh/config` pasten (Datei anlegen, falls sie nicht existiert), und `chmod 600 ~/.ssh/config` ausführen, damit SSH der Datei vertraut.
- Weitere Einträge mit dem Plus-Button oben hinzufügen. Die Vorschau kombiniert alle in einer Datei, exakt in der Reihenfolge, in der sie erscheinen.
Wann das nützlich ist
Sieben konkrete Situationen, in denen ein sauberes `ssh config` echt Zeit spart:
- Du loggst dich jeden Tag in Production ein. Statt `ssh -i ~/.ssh/prod_ed25519 -p 22 deploy@1.2.3.4` tippst du `ssh prod`. Auto-Complete funktioniert, History funktioniert, Skripte um ssh herum funktionieren.
- Das Ziel ist hinter einer Bastion. `ProxyJump` auf dem internen Host setzen und SSH hoppt transparent über den Jump-Server. Schluss mit manuellen Zwei-Stufen-Verbindungen.
- Du hast separate Keys für GitHub und GitLab. `IdentityFile` pro Host pinnen, damit der richtige Key dem richtigen Service angeboten wird. Schluss mit dem "too many authentication failures"-Error, wenn SSH jeden Key im Agent durchprobiert.
- Du brauchst einen lokalen Port für die Entwicklung. `LocalForward 5432 localhost:5432` hinzufügen und das Postgres auf dem Server taucht auf deinem Laptop auf. Kein VPN nötig.
- Du willst einen SOCKS-Proxy zum Surfen über einen Server. `DynamicForward 1080` plus Firefox auf localhost:1080 stellen, und dein Traffic geht vom Remote-Rechner raus. Praktisch für region-gesperrte Dashboards.
- Du managst 30+ Hosts. Gruppier sie mit `Host prod-*`-Patterns (der Builder schreibt einen Host pro Block, aber das Dateiformat unterstützt Wildcards, ergänze Extra-Blöcke von Hand obendrauf).
- Du willst einen lokalen Service auf einem öffentlichen Server exposen (Klassisches ngrok-Szenario). `RemoteForward 8080 localhost:3000` auf einem öffentlich erreichbaren Server, und der Port 3000 deines Laptops ist auf dem Server unter Port 8080 erreichbar.