Zur Administration mehrerer Rechner braucht man nicht unbedingt eine Lösung wie Puppet oder Cfengine. Oft genügt schon der Einsatz von SSH und seinen Verwandten.

Oft gilt es, mehrere ähnlich konfigurierte Server oder Clients zu betreuen – etwa in einer Firma, einem Internetcafe oder dem EDV-Labor einer Schule. Zwar gibt es Tools wie Puppet oder Cfengine, die dabei die Arbeit erleichtern, aber eine recht steile Lernkurve aufweisen. Für kleinere Installationen greift man da lieber zu einer Lösung mit Bordmitteln.

Als Standardtool für das Verwalten entfernter Rechner dient ssh. Die Secure Shell erlaubt das sichere Login via Netzwerk, sodass man auf dem entfernten Server fällige Änderungen vornehmen und gegebenenfalls die betroffenen Dienste neu starten kann. Das klappt bei einem Rechner zwar fein, wird bei mehreren zu betreuenden Maschinen aber schnell mühsam.

Als erster Knackpunkt erweist sich die Passworteingabe: Muss man sich hintereinander bei mehreren Rechnern einloggen, um etwas zu ändern, sollte das funktionieren, ohne das Passwort mehrfach eintippen zu müssen. Regelmäßige, automatisierte Backups müssen auch laufen, wenn der Admin gerade Urlaub macht oder krank im Bett liegt. Wie kann man das lösen?

SSH-Login ohne Passwort

Ssh erwartet die Passworteingabe normalerweise via Tastatur – es gibt keine Kommandozeilenoption, mit der sich das Passwort angeben ließe. Und das ist auch gut so: Sonst könnte sich ein anderer Benutzer über ps ax alle aktuellen Prozesse inklusive der Kommandozeilenparameter anzeigen lassen und damit das Passwort im Klartext mitlesen.

Für Anmeldungen ohne Angabe eines Passworts bietet Ssh die Möglichkeit, mit Public-Key-Kryptografie ein sicheres Login zu gewährleisten. Dazu müssen Sie nicht nur etwas wissen (Ihren Login-Namen und das zugehörige Passwort), sondern auch etwas besitzen – einen privaten Schlüssel, der zu dem öffentlichen Schlüssel auf dem Server passt.

$ cd ~/.ssh
$ ssh-keygen -N "" -f mysshkey
Generating public/private rsa key pair.
Your identification has been saved in mysshkey.
Your public key has been saved in mysshkey.pub.
The key fingerprint is:
a6:d2:c5:e9:5b:80:10:a0:a6:ef:d5:6a:3d:03:df:d0 user@hostname
The key's randomart image is:
+--[ RSA 2048]----+
|  ...            |
| .   .           |
|..  .            |
|o    . o .       |
|.     ..S        |
| .  .o.=E.       |
|  . o++o. .      |
| . ..o= .o       |
|  ...  o.        |
+-----------------+
$ ssh-copy-id -i mysshkey.pub user@myserver
Password:
Now try logging into the machine, with "ssh 'user@myserver'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Wie Sie so ein Schlüsselpaar erzeugen, zeigt Listing 1. Die Option -N "" gibt an, dass Sie keine “Passphrase” verwenden wollen – eine Tastatureingabe möchten Sie sich ja gerade ersparen. Ssh-keygen erzeugt zwei Dateien, einen privaten Key in der Datei mysshkey (den es geheimzuhalten gilt) und einen öffentlichen Schlüssel im File mysshkey.pub. Letzterer muss auf den oder die Server, auf denen Sie sich mit Ihrem privaten Schlüssel anmelden wollen.

Den Schlüsseltransfer auf den oder die Gegenstellen übernimmt dabei ssh-copy-id (Zeile 20), wobei Sie sich noch ein letztes Mal samt Passwortangabe anmelden müssen. Dabei bleibt Ihnen bei einem erstmaligen Login ebenfalls nicht erspart, dass das System nachfragt, ob Sie dem Fingerprint des entfernten Rechners vertrauen (siehe Kasten “Ausweiskontrolle”). In Zukunft aber klappt das Login dann passwortlos mit folgendem Befehl:

$ ssh -i ~/.ssh/mysshkey user@myserver

$ ssh www.example.com
The authenticity of host 'www.example.com (192.0.2.1)' can't be established.
ECDSA key fingerprint is ad:57:60:2b:53:c5:08:07:8b:b3:26:87:1d:2d:5a:b5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'www.example.com' (ECDSA) to the list of known hosts.
Password:
Last login: Sat Sep 12 14:41:29 2015 from otherhost.example.com
Have a lot of fun...

Wie gehen Sie nun aber am besten vor, um Aufgaben automatisiert zu erledigen? Die einfachste Möglichkeit bietet eine einfache For-Schleife in der Shell, wie im Beispiel aus Listing 3. Dort installiert das angegebene KOMMANDO auf den Rechnern host1 bis host4 mit dem OpenSuse-Werkzeug Zypper das Paket pssh nach. Dabei vermeidet die Zypper-Option --non-interactive Nachfragen. Ssh selbst bricht nach 10 Sekunden fruchtlose Verbindungsversuche ab (-o ConnectTimeout=10), wenn es eine Gegenstelle nicht erreichen kann, und macht mit dem nächsten Rechner weiter. Ohne diese Vorsichtsmaßnahme würde die For-Schleife “hängenbleiben” und die weiteren Rechner gar nicht bearbeiten.

HOSTS="host1 host2 host3 host4"
KOMMANDO="zypper --non-interactive install pssh"
for i in $HOSTS ; do
  ssh -o ConnectTimeout=10 -i ~/.ssh/mysshkey $i -c "$KOMMANDO"
done

Ein solche Schleife bietet fürs Erste schon eine ganz brauchbare Lösung, aber es gibt auch ausgefeiltere Methoden. Eine davon versteckt sich im Paket pssh, das im Beispiel gerade nachinstalliert wurde.

Parallel SSH

Das Programm Pssh erlaubt es, via SSH Befehle auf mehreren Rechnern parallel auszuführen [1]. Auf den Clients ist dazu nur ein laufender SSH-Server notwendig, Pssh müssen Sie nur auf dem “Steuerungsrechner” installieren. Insofern war das obige Beispiel, das Pssh auf allen Rechnern einrichtete, der Überleitung zuliebe etwas an den Haaren herbeigezogen.

Abbildung 1 zeigt eine parallele SSH-Session via Pssh. Vorab erstellen Sie eine Datei, in der Sie die zu verwendenden Rechner definieren (in unserem Beispiel heißt sie hostfile). Dort steht in jeder Zeile ein Hostname, gegebenenfalls optional mit zugehörigem Benutzernamen und Port in der Form User@Host:Port). Anschließend starten Sie das parallele Login auf den angegebenen Hosts mit folgendem Befehl:

$ pssh -i -x "-i ~/.ssh/mysshkey" -t 10 -h hostfile Kommando

Die Option -i gibt an, dass die Ausgabe im Terminal erfolgen soll, alternativ könnten Sie sie auch in Dateien – je eine für jeden Zielrechner – umleiten. Mittels -t 10 geben Sie einen Timeout von 10 Sekunden vor. Der Parameter -x schließlich legt eine Option fest, die an Ssh weitergereicht wird – hier "-i ~/.ssh/mysshkey", um den SSH-Key zu verwenden.

Abbildung 1: Parallele SSH-Sessions starten Sie mithilfe von Pssh.

Das Login hat in Abbildung 1 auf localhost funktioniert. Für www.linuxuser.de hat der Autor weder den SSH-Hostkey akzeptiert, noch überhaupt einen Account, daher funktioniert das Login nicht. Bei www.google.at bricht der Timeout das Login ab: Dort läuft (erwartungsgemäß) kein öffentlich erreichbarer SSH-Server.

Das Paket pssh bringt neben dem eigentlichen Tool pssh, mit dem Sie auf mehreren Rechnern gleichzeitig via SSH Kommandos ausführen, auch noch pscp und prsync mit, um mit scp oder rsync Dateien auf mehrere Rechner zu kopieren.

Cluster SSH

Auch Cluster SSH [2] bietet die Möglichkeit, auf mehreren Rechnern gleichzeitig zu arbeiten. Dazu rufen Sie einfach cssh host1host2 ... auf. Es öffnet sich ein kleines Eingabefenster (Abbildung 2), in dessen Eingabezeile Sie den gewünschten Befehl absetzen.

Abbildung 2: Das Eingabefenster von Cluster SSH.

Zusätzlich öffnet sich für jeden Rechner noch ein Terminalfenster. Die Eingabe aus dem Eingabefenster überträgt Cssh Zeichen für Zeichen auf die einzelnen Gegenstellen – auch wenn Sie sich vertippt haben und mit [Rückschritt] den Fehler korrigieren. Das sehen Sie auch auf den einzelnen Terminals und können dort nach dem Drücken der Eingabetaste die Ausgabe der Befehle auf den einzelnen Hosts verfolgen.

Um auf einem Rechner einen gesonderten Befehl auszuführen, verschieben Sie den Fokus auf eines der Terminals. Dort modifizieren Sie gegebenenfalls auch einen Befehl, bevor Sie im Cssh-Fenster [Eingabe] drücken und damit den Befehl auf allen Rechnern ausführen.

Bei Bedarf definieren Sie hier ähnlich wie bei Pssh die Rechner des Clusters in einer Konfigurationsdatei (/etc/clusters oder ~/.clusterssh/clusters), indem Sie einen Namen (im Beispiel aus Listing 4webserver) angeben und dann die Rechner aufführen, die dieser Klasse angehören. Beim Aufruf von Cssh geben Sie dann diese Klasse anstelle der einzelnen Rechnernamen an [3].

webserver    root@www1.example.com root@www2.example.com root@www3.example.com

Das Cluster-SSH-Paket bringt neben cssh auch noch crsh für RSH und ctel für Telnet mit. Beide Protokolle bieten im Gegensatz zu SSH allerdings keine Verschlüsselung und erscheinen daher aus heutiger Sicht irrelevant.

Einschränkungen

Bei Logins ohne Passwort sollten Sie sich Gedanken darüber machen, die Möglichkeiten der Befehlsausführung aus Sicherheitsgründen auf das unbedingt Benötigte einzuschränken – etwa auf das Triggern eines Backups, die Anzeige der aktuell laufenden Prozesse oder einen Neustart des Servers. SSH ermöglicht solche Einschränkungen über sogenannte Forced Commands und führt dann beim Login immer ein bestimmtes Kommando aus.

Wenn Sie den Schlüssel auf den Server kopieren, landet er dort in der Datei ~/.ssh/authorized_keys. Die entsprechende Zeile fängt mit ssh-rsa an (RSA steht für das verwendete Verschlüsselungsverfahren), dann folgen ein wilder Zeichensalat (Ihr Public Key) und ein optionaler Kommentar – geben Sie nichts anderes an, steht dort das User@Host des Rechners, wo Sie den Key erzeugt haben. Am Anfang der Zeile dürfen Sie bei Bedarf noch ein Forced Command eintragen:

command="ps -ef" ssh-rsa AAB3NzaC1yc..

In diesem Beispiel startet beim Einloggen mit dem angegebenen Key immer der Befehl ps -ef (Anzeige der laufenden Prozesse), auch wenn Sie Ssh ein anderes Kommando mitgegeben haben. Stattdessen könnten Sie auch ein Backup anstoßen, einen Dienst neu starten oder den Server rebooten. Da Sie beliebig viele Schlüssel generieren können, lässt sich für jede Aufgabe ein eigener Key samt zugehörigem Forced Command verwenden.

Das Ganze lässt sich noch flexibler gestalten. SSH setzt die Variable $SSH_ORIGINAL_COMMAND auf das Kommando, das Sie angegeben haben – auf diesem Weg lassen sich Kommandos “whitelisten”. Dazu verwenden Sie ein Shellskript wie in Listing 5, das Sie auf dem Server speichern und als Forced Command angeben. Dann lässt sich mit ssh -i ~/.ssh/mysshkey server.example.com df der freie Plattenspeicher abfragen, man kann mit ... ps die laufenden Prozesse anzeigen und mit .. free den freien Hauptspeicher ausgeben – und sonst nichts.

#!/bin/sh
case $SSH_ORIGINAL_COMMAND in
  "df")
    df -h
    ;;
  "ps")
    ps -ef
    ;;
  "free")
    free
    ;;
  *)
    echo "Illegales Kommando."
    exit 1
    ;;
esac

Das ist schon mal ganz gut, lässt sich aber eventuell doch missbrauchen (siehe Kasten “Tücken bei Forced Commands”). Als weitere Einschränkung können Sie mittels from="..." die Liste der Rechner einschränken, von denen aus man sich mit dem Schlüssel anmelden darf:

from="*.example.org,!chef.example.org" ssh-rsa ...

Damit kann man sich von jedem Rechner unter example.org anmelden, außer – dank der Negation durch das Ausrufezeichen – vom Rechner des Chefs aus.

Zu guter Letzt lassen sich diverse Fähigkeiten von SSH abschalten. Das Protokoll bietet ja tolle Möglichkeiten, wie unter anderem X11- und Port-Forwarding. Diese Schmankerl sollten Sie deaktivieren, wenn sie nicht unbedingt benötigt werden, da sonst ein Schelm beispielsweise durch Port-Forwarding Dienste nach außen erreichbar machen kann, von denen Sie das nicht wollen. Die entsprechenden Optionen fasst die Tabelle “Abschalten von SSH-Funktionen” kurz zusammen, genauere Informationen finden Sie in der Manpage des SSH-Daemons (man sshd).

Weitere Automatisierungen

Ein passwortloses Login lässt sich primär für Routineaufgaben nutzen, die auch ohne Zutun eines Admins erfolgen sollen, also beispielsweise für Backups. Dazu richten Sie einen Cronjob [4] ein, der die Sicherung vornimmt, wenn der Rechner gerade nicht anderweitig benötigt wird, also etwa nachts. Im einfachsten Fall kopiert das Backup per Scp die Daten des Home-Verzeichnisses (Listing 6, erste Zeile). Dabei sorgt die Option -p zwar dafür, dass Zugriffsrechte und -zeiten erhalten bleiben, das gilt aber nicht für die Eigentümer der Dateien.

Eine weitere, relativ unbekannte Möglichkeit stellt ein Datentransfer direkt via Ssh dar. Dazu legen Sie beispielsweise mit Tar ein Backup an, schreiben es nach STDOUT (- als Dateiname) – die Daten laufen dann durch die SSH-Verbindung – und kopieren es am lokalen Rechner über den Umleitungsoperator > in die Backup-Datei (Listing 6, zweite Zeile).

$ scp -r -p -i ~/.ssh/mysshkey root@meinserver:/home backupdirectory
$ ssh -i ~/.ssh/mysshkey root@meinserver "tar cvzf - /home" >meinserverbackup.tar.gz
$ rsync -az -e "ssh -i ~/.ssh/mysshkey" meinserver:/home meinserverbackup

Eine weitere Möglichkeit für Backups bietet Rsync, das dann nur die tatsächlich geänderten Daten transferiert: Der Befehl aus der letzten Zeile von Listing 6 schreibt die Daten des Home-Verzeichnisses auf dem Server meinserver ins lokale Verzeichnis meinserverbackup/. Die Option -e "ssh -i ~/.ssh/mysshkey" sorgt dafür, dass als “Remote Shell Command” Ssh mit der Option -i ~/.ssh/mysshkey zum Einsatz kommt – Sie wollen sich ja unter Verwendung des privaten Schlüssels einloggen.

Möchten Sie auch Rsync mit einem Forced Command absichern, dann geben Sie die Option -v (“verbose”) zweimal an (Listing 7). Rsync gibt dann aus, welches Kommando am entfernten Server ausgeführt wird.

$ rsync -avvz -e "ssh -i ~/.ssh/mysshkey" meinserver:/home meinserverbackup
opening connection using: ssh -i "~/.ssh/mysshkey" meinserver rsync --server --sender -vvlogDtprze.iLs . /home  (10 args)

Auf dem entfernten Server könnten Sie dann "rsync --server --sender -vvlogDtprze.iLs . /home" (ohne die beiden Verbose-Optionen) als Forced Command eintragen, sodass sich der Key tatsächlich nur für Rsync-Backups von /home einsetzen lässt. Bei --server --sender handelt es sich um interne Rsync-Optionen, die Sie im “normalen” Betrieb nie selbst angeben müssen. Die restlichen Optionen im Beispiel sorgen unter anderem dafür, dass Symlinks, Eigentümer, Gruppen, Device-Files, Zeitstempel, etc. erhalten bleiben.

Fazit

Es muss nicht immer eine der bekannten “großen” Lösungen sein: Beim Verwalten mehrerer Rechner lässt sich auch mit einfacheren Programmen die Arbeit sehr vereinfachen. SSH bietet dazu alle Grundvoraussetzungen, und mit etwas Shell-Skripting und kleinen Zusatzwerkzeugen machen Sie sich das Admin-Leben deutlich leichter.