www.Newbie-Net.de

NIS/YP mit SSH und Rsync ersetzen

Master-Slaves basiertes, sicheres Verteilen von Konfigurationsdateien mit ssh und rsync

Autor: Karsten Kruse

Inhalt

Vorwort

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.

Der Plan

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.

Voraussetzungen

Wer 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.

SSH

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.

Rsync

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.

SSH-Schlüssel verteilen

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

SSH-Test

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.

Rsync-Test

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.

Wir schreiben ein Script

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.

Automatisierung

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.

Nachwort

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.