Master-Slaves basiertes, sicheres Verteilen von Konfigurationsdateien mit ssh und
rsync
Autor: Karsten Kruse
Ich bin einer von den Typen die nie genug Rechner bekommen können, mittlerweile sind es mehr als ich zählen kann. Der Trend geht ja auch eindeutig zum n+1'ten Rechner :). Natürlich möchte ich mich an jedem Rechner einloggen können und meine gewohnte Umgebung vorfinden, das ist aber nicht so einfach. Während es ein Leichtes ist die Heimatverzeichnisse per NFS auf alle Rechner zu verteilen geht das mit Konfigurationsdateien wie den folgenden nicht mehr so einfach:
/etc/group /etc/gshadow /etc/hosts /etc/passwd /etc/resolv.conf /etc/shadow
Natürlich hat der Un*xbaukasten dafür klassische Lösungen: NIS. NIS ist die Abkürzung für Network
Information Service und wurde früher auch YP (Yellow Pages) genannt. Unglücklicherweise ist NIS alles andere
als sicher und wenig bequem weil es datenbankbasiert und somit überdimensioniert für mein Mininetzwerk ist.
Aber es gibt auch noch rdist, das im Betrieb zwar recht bequem ist, aber eine wie ich finde
recht kryptische Konfigurationssyntax hat. Von verschlüsselter Übertragung der Konfigurationsdateien auch
hier keine Spur.
Für mich kommen die klassischen Methoden also nicht in Frage, ich möchte es einfacher und vor allem
sicherer. Die Lösung liegt wie immer näher als man glaubt: ssh und rsync.
ssh kümmert sich um die Verschlüsselung und Authentifizierung und rsync verteilt
darüber die Konfigurationsdateien.
Ich werde also im folgenden erklären wie das ganze funktioniert und wie man das selber nachbauen kann. Auf den ersten Blick mag es kompliziert aussehen, aber im Gegensatz zu den klassischen Methoden ist es ein Leichtes das ganze einzurichten.
Das ganze wird folgendermaßen ablaufen. Ein Rechner wird der Master, auf ihm werden Passwörter geändert, Gruppen angelegt und alle Konfigurationsdateien verändert die verteilt werden sollen. Dann gibt es da noch die Slaves, sie bekommen vom Master die Konfigurationsdateien. Wenn jemand meint, dass die Bezeichnungen "Master" und "Slave" etwas zu archaisch sind kann man natürlich auch einfach Server und Client sagen.
Die Konfigurationsdateien werden nicht in Echtzeit verteilt, normalerweise sollten Intervalle von 5
Minuten ausreichen. Das heißt, wenn ein User sein Passwort ändern will muss er das erstens auf dem
Master tun und zweitens 5 Minuten warten bis die Änderung auf allen Slaves übernommen ist. Natürlich kann
man das Aktualisieren auch von Hand veranlassen falls es mal notwendig sein sollte. Nochmal andersherum:
Sollte ein User sein Passwort auf einem Slave ändern ist die Änderung in 5 Minuten verloren. In dieser
Beziehung ist NIS im Vorteil, doch der Sicherheitsgewinn macht das mehr als wett. Die Intervalle werden
später von cron angestoßen, doch dazu komme ich noch.
VoraussetzungenWer bis hierher gelesen hat dem ist sicher aufgefallen, dass wir SSH und Rsync
installieren müssen. Hier erkläre ich kurz wie ihr an die entsprechenden Programme kommt.
Nahezu jedes Un*xartige Betriebssystem hat in diesen Tagen ssh vorinstalliert. Das ist gut.
Sollte das bei euch nicht so sein, oder wollt ihr eine neue Version, dann bleiben drei Wege:
Im weiteren gehe ich davon aus, dass sshd auf Master und Slaves läuft und man sich via
ssh anmelden kann.
Für rsync gilt praktisch das gleiche wie für ssh, einzig die Bezugsadresse ist
eine andere. Viele Betriebssysteme haben kein rsync und bieten auch keine fertigen Pakete an.
Da bleibt dann oft nur das Selberkompilieren. Die folgende Seite hat die Anleitung dazu, die Sourcen und
auch ein paar fertige Pakete: http://rsync.samba.org/rsync/.
Auch hier gehe ich davon aus das rsync installiert wurde.
Wie ssh im einzelnen funktioniert möchte ich jetzt nicht erklären, das würde den Rahmen
sprengen und kann ja auch einfach in der SSH-Dokumentation nachgelesen werden. Was wir jetzt brauchen ist
ein Weg unsere Daten verschlüsselt zu übertragen und das ganze ohne Passworteingabe zu erledigen, wer
möchte schon alle 5 Minuten sein Passwort eingeben. Um das zu realisieren, werden wir als Root auf dem
Master ein Schlüsselpaar ohne Passwort anlegen und den öffentlichen Teil des Schlüssels auf die Slaves
verteilen.
Melden wir uns also auf dem Master an und geben als Root folgendes ein:
ssh-keygen -b 1024 -N ""
Eventuell muss bei neueren Linux-Distributionen (z.b. SuSE 8.0) der Schlüsseltyp explizit angegeben werden. Per Default wird ein RSA-Key (Version 1) erstellt. Mit diesem Befehl wird ein DSA-Key (Version 2) erstellt:
ssh-keygen -b 1024 -t DSA -N ""
Dank an Tobias Mucke für diesen Hinweis :).
Wenn das Programm uns fragt in welche Datei der Schlüssel geschrieben werden soll akzeptieren wir
einfach die Vorgabe mit Return. Unser Schlüsselpaar sollte jetzt als /root/.ssh/identity.pub
und /root/.ssh/identity vorliegen.
Die Datei /root/.ssh/identity.pub muss jetzt auf die Slaves verteilt werden. Dazu kann man
Mail, NFS oder FTP nehmen, je nach Möglichkeiten. Leg also die Datei als
/root/.ssh/authorized_keys auf den Slaves ab. /root/.ssh/identity.pub auf dem
Master und /root/.ssh/authorized_keys auf dem Slave sind also identisch.
Danach werden die Rechte für die Datei /root/.ssh/authorized_keys auf dem Slave mit
folgendem Kommando festgelegt:
chmod 600 /root/.ssh/authorized_keys
Testen wir ob alles glatt gegangen ist mit folgendem Kommando auf dem Master:
ssh root@slave1
Ein erster Verbindungsdialog sieht etwa so aus:
master:/ # ssh root@slave1 The authenticity of host 'slave1 (192.168.1.20)' can't be established. RSA1 key fingerprint is 75:83:2c:a0:be:74:be:ea:29:c4:7e:13:41:ad:34:36. Are you sure you want to continue connecting (yes/no)?
Das bejahen wir und werden mit dieser Ausgabe belohnt:
Warning: Permanently added 'tecneeq' (RSA1) to the list of known hosts. Last login: Thu Mar 28 16:48:28 2002 Have a lot of fun... slave:~ #
Wir loggen uns aus und nochmal ein, dann sehen wir das wir uns anmelden ohne ein Passwort anzugeben,
verschlüsselt, sicher und einfach. Fein, ssh ist vorbereitet und wir können jetzt zu
rsync kommen.
Um rsync zu testen legen wir auf dem Master eine Testdatei an:
echo "Dies ist eine Testdatei." > /tmp/testdatei.txt
Verteilen wir nun die Testdatei vom Master aus auf einen der Slaves mit diesem Befehl:
rsync -p -e ssh /tmp/testdatei.txt slave1:/tmp/testdatei.txt
Die Datei /tmp/testdatei.txt sollte jetzt auch auf dem Slave zu finden sein. Ist das nicht der Fall ist
entweder rsync nicht korrekt installiert oder rsync ist nicht in der
PATH-Variable. Jetzt testen wir ob auch ein ändern der Datei auf dem Master zum Slave übertragen wird:
echo "Hier eine Aenderung" >> /tmp/testdatei.txt rsync -p -e ssh /tmp/testdatei.txt slave1:/tmp/testdatei.txt
Alles hat geklappt? Dann wird es Zeit für das Script und die Automatisierung.
Um nicht für jede Datei und jeden Slave einen Befehl eingeben zu müssen habe ich mir folgendes Script
geschrieben und als /usr/local/sbin/syncslaves abgelegt:
#!/bin/sh
#
# syncslaves - Verteilen von Konfigurationsdateien
#
# Zu snchronisierende Rechner
slaves="slave1 slave2 slave3"
# Dateien die verteilt werden
files="/etc/group /etc/gshadow /etc/hosts /etc/passwd /etc/resolv.conf /etc/shadow"
for slave in $slaves ; do
for file in $files ; do
rsync -p -e ssh $file $slave:$file
done
done
Bevor du dieses Script startest, solltest du zur Sicherheit alle Dateien die verteilt werden sollen auf
den Slaves sichern. Nur für den Fall das irgendetwas furchtbar schief geht ;). Natürlich musst du die
files und slaves anpassen.
Es wird Zeit das Script zu starten und auf den Slaves das Ergebnis zu überprüfen, wenn alles glatt
gegangen ist können wir das ganze mit cron automatisieren.
Die Syntax von cron sollte uns allen bekannt sein, notfalls kann man das ja in den
entsprechenden Manpages nachlesen. Mein Eintrag den ich mit crontab -e auf dem Master mache
sieht so aus:
*/5 * * * * /usr/local/sbin/syncslaves
Fertig.
Als letzte Arbeiten könnte man auf den Slaves das Programm passwd entschärfen, es hat jetzt
keine Funktion mehr. Ich habe es umbenannt und die Rechte geändert.
chmod 644 /bin/passwd mv /bin/passwd /bin/passwd.disabled
Das ist natürlich nur notwendig wenn ihr wie ich die Passwortdateien verteilt. Die User zu informieren
das Passwortänderungen nur noch auf dem Master möglich sind sollte einfach sein. Alternativ könnte man
/bin/passwd auf den Slaves auch durch ein Script ersetzen das via rsh auf dem Master das
Passwort ändert und das Synchronisieren gleich mit anstößt. Diese Lösung wäre für die User ganz
transparent.
Dank an mkl0815(at)k-networking(dot)de Mario Keller für diesen Hinweis :).
Ich habe angenommen, dass die Heimatverzeichnisse vom Master zu den Slaves per NFS exportiert werden. Ist das nicht der Fall, muss nach Anlegen eines neuen Users auf dem Master auch ein Heimatverzeichnis auf den Slaves erstellt werden.
Möglicherweise hast du Probleme oder Tipps die du mit anderen teilen möchtest? Oder du hast Fehler entdeckt? Am besten schreibst du mir dann eine Mail tecneeq(at)tecneeq(dot)de. Wie dem auch sei, ich wünsche wie immer viel Spaß damit :).
Karsten Kruse aus dem Land des binären Weihwassers für www.newbie-net.de und www.pro-linux.de, ich gebe zurück ins Studio.