Lektion 5: Arbeiten mit entfernten Rechnern

Im laufe eines normalen Tages arbeite ich durchschnittlich an 5 Rechnern. Zwei davon stehen bei mir im Zimmer, der Rest steht woanders (weiter als 5 Schritte entfernt, also “Remote”). Nun, ich könnte wie z.b. in Windows-Kreisen durchaus üblich, vnc oder Remote-X verwenden um auf den Kisten was zu tun. Ist aber alles langsam (z.b. die DSL-Kiste zuhause) oder X (Grafikoberfläche) ist gar nicht installiert (wozu auch, auf dem Server). Also wie nutze ich die Rechner entfernt? Klar, mit ssh. ssh steht für “secure shell” und eignet sich prinzipiell für verschlüsselte, authentifizierte Datenübertragung. Mit dem Befehl ssh user@ein.anderer.rechner.example kann ich mich bei dem Rechner “ein.anderer.rechner.example” unter dem Nutzerkonto “user” anmelden, ich werde nach dem Passwort gefragt und ich bin drin. Sehr einfache, schnelle Geschichte. Was aber wenn ich nicht ständig mein Passwort (wenn auch verschlüsselt) durch das (Inter-)Netz schicken will? Dafür kennt ssh andere Authentifizierungsmethoden. Zum Beispiel public/private Schlüsselpaare, wie sie auch bei Email-Verschlüsselung (gpg/pgp) eingesetzt werden. Das Konzept in Kurzform: Der Benutzer erzeugt ein Schlüsselpaar (einen öffentlichen, einen privaten Schlüssel). Diese Schlüssel werden auf dem lokalen Rechner gespeichert. Auf dem entfernten Rechner, bei dem man sich einloggen will speichert man den öffentlichen Schlüssel. Möchte man sich nun auf dem entfernten Rechner anmelden, sendet der entfernte Rechner eine, mit dem öffentlichen Schlüssel verschlüsselte Zufallszahl, welche der lokale Rechner mit dem privaten Schlüssel (und evtl Passwortabfrage für diesen) entschlüsselt. Die entschlüsselte Zahl wird zurück an den entfernten Rechner gesendet, welcher nun (wenn die Zahlen übereinstimmen) den Benutzer “authentifiziert” hat. Dabei wurde weder der öffentliche noch der private Schlüssel über das Netz geschickt, lediglich eine Zufallszahl. Sehr elegant, oder? (nebenbei: hier (unter anderem) erkennt man auch die Wichtigkeit von “zufälligen” Zufallszahlen für Verschlüsselungsverfahren.; achja nochwas: der entfernte Rechner authentifiziert sich auch selbst: gleiches Prinzip – öffentlicher Schlüssel bei uns, privater Schlüssel auf entferntem Rechner)
Erzeugung des Schlüsselpaares (für ssh Version 2):
ssh-keygen -t dsa
Man sollte für den privaten Schlüssel ein Passwort setzen, so wird selbst ein gestohlener privater Schlüssel nicht automatisch zum Einfallstor. Die Schlüssel werden unter ~/.ssh/iddsa (privater) und ~/.ssh/iddsa.pub (öffentlicher) abgelegt. Nun muss man dem entfernten Rechner seinen öffentlichen Schlüssel mitteilen. Die öffentlichen Schlüssel (es können mehrere sein) liegen auf dem entfernten Rechner unter ~/.ssh/authorizedkeys , pro Zeile ein Schlüssel. Falls dort die Datei noch nicht Existiert, kann man die iddsa.pub einfach drüberkopieren. Zu diesem Zweck kann jetzt ein anderes Programm der ssh-Familie zum Einsatz kommen: scp – Secure Copy. Kopieren von Dateien über verschlüsselte Verbindung. Siehe Manpage. scp ~/.ssh/iddsa.pub user@ein.anderer.rechner.example:.ssh/authorizedkeys
Damit sollte das Problem des “Passwort über Netzwerk” gelöst sein. Nächstes Problem: Ich bin zu faul ständig mein langes, kompliziertes (daher: sicheres) Passwort einzugeben. Lösung: ssh-agent. Diesem Programm bringt man mittels ssh-add das Passwort für den/die privaten Schlüssel bei, ssh verwendet den Agenten um die Zufallszahl zu entschlüsseln. Den Agenten einzurichten kann etwas kompliziert sein. Ich verwende trotz aller Shell-Spielereien eine graphische Oberfläche (X+WindowMaker um genau zu sein). Damit alle Programme (unterhalb von WindowMaker) den Agenten verwenden können, lasse ich den WindowMaker durch ssh-agent starten. Wie das genau geht, ist in den Distributionen ziemlich unterschiedlich; Google hilft.
ssh bietet ziemlich viele Möglichkeiten. Ich kann z.b. auch sichere Tunnels graben, entfernte graphische Programme verschlüsselt starten, den privaten Schlüssel aus Wechselmedien (z.b. USB-Stick, Smartcard) lesen, gzip Kompression der Daten aktivieren et cetera.
Ich finde ausserdem, dass es wichtig ist auf die Konfigurationsdatei hinzuweisen. Dort kann man z.b. host-spezifisch Einstellungen vornehmen. Wenn ich z.b. von einer DSL-Leitung mich auf Uni-Rechnern einloggen möchte, ist eine gzip Kompression sinnvoll, der Hostname ist zu lang, die Verbindung zum Agenten soll weitergereicht werden, X soll weitergeleitet werden und der Nutzername ist auch ein anderer. Die Kommandozeile würde lauten:
ssh -X -A -C ringehah@sshproxy.hrz.tu-freiberg.de
Wenn ich nun aber diesen Text in der ~/.ssh/config stehen hab:

Host sshproxy
HostName sshproxy.hrz.tu-freiberg.de
User ringehah
ForwardAgent yes
Compression yes
ForwardX11 yes

dann verkürzt sich die Kommandozeile auf ssh sshproxy – schick, oder?

4 Kommentare zu “Lektion 5: Arbeiten mit entfernten Rechnern”

  1. chrono

    um auf den vielen Rechnern mit mehreren xterms nicht durcheinander zu kommen, lass’ ich von der .bash_profile immer nen prompt in der form [nutzer@host(ttyX):dir] farbig anzeigen. nette info sammlungen gibts hier:
    http://www-106.ibm.com/developerworks/linux/library/l-tip-prompt/
    http://www.linux.org/docs/ldp/howto/Bash-Prompt-HOWTO/

  2. Claus

    Weiter so! Habe zu Deiner Site gleich einen Link gesetzt! Linux forever ;-) ! Spass beiseite – ich finde Deine Site sehr informativ! Ein anderes (nicht meins) Linux-Blog ist http://linux.blogger.de von Tom! Vielleicht kennst Du das aber auch schon!

  3. knipser

    Frontend zum ssh-agent: keychain http://www.gentoo.org/proj/en/keychain.xml
    Die Schlüssel sind dann nicht nur unter der aktuellen login-shell sondern global erreichbar. Damit sind einmal importierte Schlüssel auf jeder Textkonsole verwendbar.
    Damit ist es nicht mehr nötig den X-Server durch den ssh-agent zu starten.

  4. knipser

    Ergänzung zu keychain: folgende zwei Zeilen in die .bashrc funktionieren für mich:
    /usr/bin/keychain ~/.ssh/id_dsa
    source ~/.keychain/${HOSTNAME}-sh

Einen Kommentar schreiben: