32.5Zusatzwerkzeuge
Für intensive SSH-Nutzer existieren diverse Zusatzwerkzeuge, um die Nutzung von SSH effizienter oder sicherer zu gestalten. Einige dieser Werkzeuge möchte ich Ihnen hier ganz kurz vorstellen.
Cluster SSH
Cluster SSH – oder kurz CSSH – ist ein Perl-Script, mit dem Sie mehrere SSH-Verbindungen initiieren können. Für jede Verbindung wird ein eigenes Xterm-Fenster geöffnet, wobei die Textfarbe je nach Server variiert. Die Farbe ist nicht einstellbar, bleibt aber für einen Server immer gleich. Wenn Sie CSSH eine Weile benutzen, können Sie allein anhand der Farben zuordnen, auf welchem Server Sie gerade arbeiten.
Der eigentliche Clou von CSSH besteht aber darin, dass Sie Kommandos nicht nur direkt in den Xterm-Fenstern eintippen können, sondern auch in einer Texteingabebox des winzigen CSSH-Fensters. Diese Eingabe wird dann auf alle offenen Fenster vervielfacht. Wenn Sie also auf drei Ubuntu- oder Debian-Servern ein Update durchführen möchten, loggen Sie sich zuerst mittels CSSH auf allen drei Servern ein und geben dann im CSSH-Steuerungsfenster einmal apt-get dist-upgrade ein. Das Kommando wird damit auf allen drei Servern ausgeführt.
Cluster SSH kann auf vielen Distributionen als Paket clusterssh installiert werden. Sollte das Paket in Ihrer Distribution fehlen, finden Sie Cluster SSH hier zum Download:
http://sourceforge.net/projects/clusterssh
Parallel SSH
Die Python-Script-Sammlung Parallel SSH (Paketname pssh) hat gewisse Ähnlichkeiten zu CSSH. Das in Parallel SSH enthaltene Kommando pssh eignet sich ebenfalls dazu, ein Kommando auf vielen via SSH erreichbaren Servern auszuführen – parallel eben. Der entscheidende Unterschied zu CSSH besteht darin, dass Parallel SSH nicht zur interaktiven Nutzung, sondern zur automatisierten Script-Verarbeitung gedacht ist. Dazu speichern Sie zuerst die Hostnamen oder IP-Adressen in eine Textdatei und führen die gewünschten Kommandos dann via Parallel SSH auf allen Hosts aus:
Wenn Sie die Ausgaben von Kommandos speichern möchten, geben Sie mit -o ein Ausgabeverzeichnis an. Dort speichert pssh für jeden Host eine Datei mit dem entsprechenden Namen.
Administrative Arbeiten erfordern bei pssh einen root-Login auf den Servern. Unter Ubuntu gelingt das standardmäßig nicht. Sie können aber mit passwd ein root-Passwort festlegen und danach mit ssh-copy-id den eigenen Schlüssel kopieren. pssh setzt voraus, dass eine Authentifizierung mit Schlüssel möglich ist, oder dass sich das Hinterprogramm ssh-agent um die Authentifizierung kümmert.
Das Paket pssh stellt auch die Kommandos pscp und pnuke zur Verfügung. Mit pscp können Sie eine Datei über viele Rechner verteilen. Das Zielverzeichnis muss dabei absolut angegeben werden. pnuke beendet auf allen Hosts einen Prozess durch kill -9. Anwendungsbeispiele zu pssh, pscp und pnuke finden Sie hier:
http://www.linux-magazin.de/Ausgaben/2008/11/Und-wenn-ja-so-viele
Mosh
Es ist nahezu unmöglich, SSH während einer Zugfahrt zu benutzen: Ständige Verbindungsabbrüche zwingen Sie, sich immer wieder neu einzuloggen. Abhilfe schafft Mosh (Mobile Shell), eine SSH-Alternative zur Nutzung eigens für instabile Netzwerkverbindungen.
Bevor mosh verwendet werden kann, muss das gleichnamige Paket sowohl auf dem Server als auch auf dem Client installiert werden. Anschließend stellen Sie die Verbindung analog zu Verbindungen mit ssh her:
mosh verwendet SSH für den Verbindungsaufbau und startet dann auf dem externen Host das Programm mosh-server mit den Rechten des Benutzers, zu dem Sie die Verbindung hergestellt haben. mosh-server läuft also anders als sshd nicht ständig als Dienst, sondern nur bei Bedarf. Die weitere Kommunikation erfolgt dann über das Protokoll UDP (nicht TCP) und über einen Port zwischen 60000 und 61000. Diese Ports dürfen also nicht durch eine Firewall blockiert sein.
Weitere Details zu mosh können Sie auf der Projektwebseite nachlesen:
Login mit dem Google-Authenticator
Bei der Arbeit mit SSH sind zwei Authentifizierungsverfahren üblich: ein simples Passwort (flexibel, aber sicherheitstechnisch nicht perfekt) oder die Verwendung von Schlüsseln (sicherer, erfordert aber, dass Sie immer Ihr Notebook mit dem Schlüssel bei sich haben). Eine dritte Variante besteht darin, eine Zwei-Faktor-Authentifizierung einzurichten. Bei jedem Login müssen Sie zusätzlich zum regulären Passwort einen nur für kurze Zeit gültigen Einmal-Code eingeben. Dieser Code wird von einer Smartphone-App generiert.
Gut geeignet für derartige Zwecke ist die App Google Authenticator, die es kostenlos für iOS und Android gibt. Diese App arbeitet rein lokal. Weder die Schlüssel noch die Einmal-Codes werden auf einen Google-Server übertragen.
Abbildung 32.1Einrichtung von Google Authenticator
Auf dem abzusichernden Linux-Server installieren Sie das Paket libpam-google-authenticator. Es enthält ein PAM-Modul zur Kontrolle der Einmal-Codes sowie das Kommando google-authenticator zum Einrichten der Authentifizierung. Dieses Kommando führen Sie für den Account aus, in dem Sie sich anmelden möchten. Es zeigt einen QR-Code an (siehe Abbildung 32.1), den Sie mit der Google-Authenticator-App Ihres Smartphones einscannen. Auf diese Weise richten Sie in der Smartphone-App ein neues Konto ein. Damit ist der App Ihr Konto bekannt, und sie beginnt sofort damit, sechsstellige Einmal-Codes zu erzeugen. Jeder Code ist 30 Sekunden lang gültig. Danach wird automatisch der nächste Code erzeugt.
Das Kommando google-authenticator gibt außerdem fünf Emergency Scratch Codes aus. Auch dabei handelt es sich um Einmal-Codes, allerdings ohne zeitliche Begrenzung. Sollten Sie Ihr Smartphone nicht bei sich haben, können Sie sich zur Not mit einem dieser Codes einloggen (aber nur einmal!). Bevor die fünf Codes aufgebraucht sind, fügen Sie der Datei .google_authenticator mit einem Editor neue Codes hinzu.
Damit das PAM-Modul verwendet wird, verändern Sie die folgenden beiden Konfigurationsdateien:
Mit service sshd restart starten Sie schließlich den SSH-Server neu.
Ein Login beim Server sieht nun so aus:
Vorsicht
Auf dem Server können sich nun nur noch Benutzer anmelden, die zuvor für ihr Konto google-authenticator ausgeführt haben.
Probieren Sie das Verfahren zuerst in einer virtuellen Maschine aus, nicht auf einem realen Server! Wenn Sie Google Authenticator für einen Server einrichten, zu dem Sie keinen physischen Zugriff haben, sollten Sie während der gesamten Arbeiten bis zum Abschluss eines erfolgreichen Tests unbedingt in einer getrennten SSH-Session mit root-Rechten eingeloggt bleiben. So können Sie zur Not über diese Verbindung Reparaturarbeiten durchführen. Andernfalls kann es Ihnen passieren, dass Sie sich auf Ihrem eigenen Server nicht mehr anmelden können, falls bei der Konfiguration irgendetwas schiefgeht!
Die zusätzliche Sicherheit erkaufen Sie sich mit einer neuen Abhängigkeit: Wenn Sie Ihr Smartphone irgendwo liegen gelassen haben oder der Akku leer ist, dann gelingt der SSH-Login nur mit einem der Notfall-Codes.