Wir schreiben den dritten Dezember; also befinden wir uns im dritten Teil unseres CLI-Adventskalenders. Heute beschäftigen wir uns mit ssh.
Die Adventszeit ist eine Zeit, um Verbindungen herzustellen. Sei es, dass wir Verwandte anrufen mit denen wir schon ewig nicht gesprochen haben, oder dass wir Server debuggen, die unter dem Traffic des Weihnachtsgeschäfts in die Knie gegangen sind.
SSH!
Die Möglichkeit, mit Maschinen nah und fern Kontakt aufzunehmen und direkte Kontrolle zu übernehmen. Ich hatte bis vor kurzem noch gedacht, dass wir heutzutage von Zeiten des Cowboy Codings und Fixing in Production weggekommen sind. Der ganze Punkt hinter DevOps ist es ja, das Administrieren von Maschinen durch skalierende Indirektionen zu lösen. Nichtsdestotrotz scheint der schnelle Blick in eine Maschine zum Lösen von Fehlerursachen bis heute unverzichtbar zu sein. Das versichert mir zumindest meine Frau, die grafische Oberflächen viel lieber mag als ich, aber trotzdem erstaunlich oft ssh benutzt.
Und ssh hat wieder viele kleine Adventsschmankerl, die nur Wenige einsetzen.
Anstatt sich ganz normal einzuloggen und eine Shell zu bekommen
ssh -i ./identity_file -p 1337 eric@blog.mayflower.de
kann man auch einen einfachen Befehl lostreten und den Output lokal bewundern.
ssh -t eric@mondbasis.moon 'ping mayflower.de'
Und wer sagt, dass ssh nur für Terminalliebhaber ist? Es unterstützt auch X11-Forwarding …
ssh -X eric@anderes-laptop.local
… und die Möglichkeit, grafische Applikationen remote mit lokaler GUI laufen zu lassen.
ssh -X -t eric@gaming-pc.local 'firefox'
Und natürlich kann ich auch einfach ein Dateisystem mounten, um Dateien auf der anderen Maschine direkt mit meinen lokalen Programmen zu bearbeiten.
sshfs eric@example.com:/home/eric /media/server
Unmounten geht übrigens mit fusermount -u /media/server.
Einfach nur Dateien übertragen geht mit scp.
# upload scp datei.txt eric@filesharing.example.com:~/ # download scp eric@filesharing.example.com:~/video.mp4 .
Bequemlichkeitsfeatures für Gewohnheits-SSH-ende
Na gut, na gut. Alles ganz nette Spielsachen, aber die meisten SSH-Nutzer wollen sich einfach nur zeiteffizient mit diversen Maschinen verbinden und arbeiten. Ich höre euch. Die nächsten Adventsschmankerl sind für euch.
- commandline-options
- ~/.ssh/config
- System-weit: /etc/ssh/ssh_config
In besagter Konfiguration können wir Aliases für Hostnamen bestimmen.
Host blog HostName blog.mayflower.de User eric PreferredAuthentications publickey IdentityFile ~/.ssh/blog_key
… und uns einfacher verbinden – dem Beispiel folgend genügt ein ssh blog.
Wenn man sich per Key authentifiziert, ist das auch alles, was man zum verbinden braucht. Das kann man übrigens auch wildcarden:
Host blog filesharing mondbasis www Hostname %h.mayflower.de ...
Das schont die Umwelt, weil sich Abnutzung an der Tastatur verringert.
Für alle die, die sich von einer Maschine auf eine andere Maschinen einloggen müssen, lassen sich diese Ketten nicht nur explizit über die Kommandozeile verkürzen …
ssh -J blog admin@geheimhq.mayflower.de
… sondern auch direkt in der Config vordefinieren.
Host geheimhq Hostname geheimhq.mayflower.de ProxyJump blog User admin PreferredAuthentications publickey IdentityFile ~/.ssh/illuminati.ed25519
Lasst uns Löcher in Firewalls bohren!
Manchmal wurde nicht genug nachgedacht beim Konfigurieren von Firewalls und IDSen. Oft haben wir nicht die Berechtigungen, Änderungen an der Konfiguration vorzunehmen – aber trotzdem den Zwang, wichtige Anwendungen mit entfernten Servern zu verbinden.
ssh -N -L localhost:80:moonbase.mayflower.local:80 eric@entrygate.mayflower.de
Portforwards können manchmal ein Gehirntwister sein – und hier sind drei Systeme involviert. Ich erkläre es also mal ganz langsam und vorsichtig:
In diesem Beispiel (alle Systeme übrigens fiktiv) ist entrygate.mayflower.de eine Maschine, auf die wir uns ganz normal mit SSH verbinden.
Die Maschine moonbase.mayflower.local ist eine Maschine im selben lokalen Netzwerk wie entrygate. Ich kann mich mit entrygate verbinden, nicht aber mit moonbase, weil die Firewall es nicht zulässt. Was mache ich?
Ich sage ssh, dass alles was ich auf meinen eigenen Port 80 sende (lokal bei mir) über entrygate an moonbase weitergeleitet werden soll. In diesem Fall kann ich also meinen Browser auf localhost ansetzen und bekomme die Antwort des moonbase-Webservers.
Das kann man natürlich auch genauso gut mit MySQL machen.
ssh -N -L localhost:3306:moonbase.mayflower.local:3306 eric@entrygate.mayflower.de
Ich kann dann mein buntes GUI-Tool auf meinem Desktop benutzen, um mich direkt auf die Datenbank auf moonbase zu verbinden. Das geht natürlich auch umgekehrt:
ssh -N -R entrygate.mayflower.de:80:localhost:80 eric@entrygate.mayflower.de
Jetzt können sich Leute mit dem Browser auf entrygate verbinden und landen auf dem Webserver der lokal bei mir läuft. Letzten Endes kann ich das System auch gleich zu meinem Proxyserver machen.
sudo ssh -N -D localhost:8080 eric@entrygate.mayflower.de
Das System fungiert jetzt als SOCKS5-Proxy für mich. Ich kann es zum Beispiel in meinem Browser als solchen nutzen, um meinen Webtraffic hindurch zu leiten.
Talks, die ihre Zeit Wert sind
Wer eine gemütlichere Einführung in SSH will (Wie generiere ich Keys und kriege sie auf den Server?) oder noch tiefer einsteigen möchte (Wie uploade ich meinen Key in mein TPM und wie richte ich mein SSH mit 2FA und Yubikey ein?), dem empfehle ich diese zwei Talks von Martin Leyrer, von denen ich mich definitiv habe inspirieren lassen:
In der Post-Corona-Zeit sind Teams immer mehr auf verschiedene Standorte verteilt. Hinter dem verschwommenen Hintergrund diverser Kollegen kann sich ein Büro in Würzburg, ein Balkon in Berlin oder ein Strand in Portugal verstecken und wir würden es nicht merken (wenn es uns überhaupt interessiert). Dieselbe Art von Unabhängigkeit bieten auch Terminals.
Meine Kommandozeile kann gerade einen Server in Tokyo steuern und nur die Verzögerung – wenn ich eine bemerke – macht den Unterschied zu einem Server in meinem Keller. Klar ist das ganze auch mit graphischen Oberflächen möglich, aber diese stellen meistens einen Monofokus her. Ich bin entweder auf diesem Desktop oder jenem unterwegs. Mit dem Terminal (und evtl. Tools wie tmux) kann jedes Fenster auf einen anderen Kontinent zeigen.
Ob ein Prompt lokal bei mir, direkt auf der Maschine läuft, oder in einem Container, oder in einer VM, auf einem Server hier oder irgendwo, oder in meinem Kühlschrank, er ist nur Fenster auf meinem Laptopbildschirm.
Terminals sind das Tool der Wahl, wenn ich die direkte Kontrolle über eine ganze Reihe verteilter Systeme übernehmen möchte. Sie können auch leicht Unabhängigkeit von Geräten bieten. Klar, kann ich mit dem Laptop meiner Wahl einen Remote-Desktop auf meinen Arbeitsserver aufmachen, aber textbasierte Terminalfenster bieten dann doch eine viel größere Flexibilität.
Noch größer ist der Vorteil für die, die mit Editoren wie vim oder Emacs auch ihren Code auf dem Terminal schreiben. Es kommt wenig an das Gefühl ran, sich per ssh auf den eigenen Server zu verbinden und alles ist noch genau in dem Zustand, dass ich sofort weiterarbeiten kann.
Schreibe einen Kommentar