Google denkt beim Thema Sicherheitsautomatik sofort an Hebelschneidemaschinen, obwohl eine funktionierende Sicherheitsautomatik eigentlich in jedem Lebensbereich ihre Berechtigung hat. Besonders natürlich bei meinem Steckenpferd, der Datensicherung.
Im Rahmen meines hastig hingekritzelten Backup-Eintrags hatte ich zwar Pete Freitags exzellente Anleitung zur Einrichtung eines inkrementellen rsync-Backups unter Mac OS X verlinkt, war aber nicht auf die von ihm erwähnte Automatisierung mitels Public Key Authentication eingegangen. Beides – sowohl den Eindruck unziemlicher Hast als auch das Versäumnis – möchte ich natürlich korrigieren.
Zunächst muss der Server vorbereitet werden: Benötigt werden ein dedizierter Backup-Nutzer (der denselben Namen tragen sollte wie der Nutzer, in dessen Namen das Backup auf dem lokalen Rechner gestartet wird), ein Backup-Ordner in dessen Nutzerverzeichnis sowie das Verzeichnis .ssh:
groupadd backup useradd -gbackup -s /bin/rbash jan su - jan mkdir .ssh chown jan:backup .ssh chmod 700 .ssh mkdir backup chown jan:backup backup
Nun wenden wir uns dem lokalen Rechner zu, erzeugen dort ein Schlüsselpaar (ohne Passwort) und kopieren den öffentlichen Teil des Schlüssels auf den Server:
ssh-keygen -t rsa scp ~/.ssh/id_rsa.pub remote.server.com:.ssh/authorized_keys2 ssh remote.server.com
Achtung: Wenn der Backup-Nutzer nicht neu angelegt wurde und die Datei authorized_keys2 bereits existiert, sollte der öffentliche Schlüssel natürlich nicht die gesamte Datei überschreiben, sondern zum bestehenden Inhalt hinzugefügt werden.
Der letzte Befehl sollte ohne Eingabe eines Passworts zu einer SSH-Verbindung zwischen lokalem Rechner und remote.server.com führen. Dieses Setup ist natürlich ein wenig riskant, wie Mr. Freitag einräumt:
Now keep in mind that all someone needs to login to the remote server, is the file on your local machine ~/.ssh/id_rsa, so make sure it is secure.
Andere Anleitungen raten deshalb strikt von einem passwortlosem Schlüsselpaar ab und empfehlen stattdessen den Einsatz von ssh-agent, um die wiederholte Eingabe eines Passworts im Rahmen einer Session zu vermeiden. Die obige Beschränkung des Backup-Nutzers auf rbash bietet im Vergleich dazu keine echte Sicherheit, aber immerhin bleibt der Schreibzugriff eines Angreifers zunächst auf das Nutzerverzeichnis beschränkt, das wiederum ausschließlich die verschlüsselten Daten des Backups enthält.
Jetzt fehlt nur noch rsync selbst. Anders als in vielen Anleitungen empfohlen, verwende ich nicht den Archiv-Parameter (-a), weil die darin enthaltenen Parameter (-rlptgoD) in Bezug auf mein Backup-Konzept irrelevant oder inkompatibel sind. Das gilt vor allem für die Behandlung von Symbolic Links: Statt sie als Links zu kopieren (-l), sollen die dahinterstehenden Referenten übertragen werden (-L). Da ich mein Backup-Set schon seit längerem mit Symbolic Links zusammenstelle, brauche ich das große L. Darüber hinaus sollte das Backup informativ (-i bzw. -v) und rekursiv (-r) ablaufen, geänderte Dateien anhand ihrer geänderten checksum erkennen (-c) sowie die Zeitstempel der Dateien bewahren (-t). Von der Übertragung der HFS+-Metadaten (-X bzw. -E in älteren rsync-Versionen) auf fremde Dateisysteme habe ich mich dagegen nach längerer Recherche verabschiedet. Der vollständige rsync-Aufruf wird jedenfalls in backupper.sh verpackt –
!#/bin/bash rsync -e "ssh" -ivcrLt --delete-after --progress /Users/jan/Backup/ remote.server.com:~/backup > ~/Logs/backupper.log
– das wiederum als cronjob eingetragen wird:
55 17 * * * ~/Library/Scripts/backupper.sh
Ein ähnliches Verfahren gibt es übrigens auch für SMB-Freigaben, deren Zugangsdaten unter Mac OS X im Ordner ~/Library/Preferences/nsmb.conf hinterlegt werden können:
[default] minauth=none # this is the server name and ip [myserver] address=192.168.12.34 [myserver:user] password=mypass
Das entsprechende Skript für den Eintrag als cronjob muss neben dem rsync-Aufruf auch die Freigabe einbinden (und nach dem Backup wieder auswerfen):
#!bin/bash mkdir /Volumes/mountp mount_smbfs //user@myserver/myshare /Volumes/mountp rsync rsync -ivcrLt --delete-after --progress /Users/user/Backup/ /Volumes/mountp/backup >> ~/Logs/backup.log umount /Volumes/mountp
Natürlich gilt für das Klartext-Passwort in nsmb.conf dasselbe wie für den passwortlosen privaten Schlüssel. Aber leben wir nicht alle gern wild und gefährlich?