rsync ssh mit Schlüsselpaaren und LaunchDaemon

[silmor]

Hallo!

Ich habe folgendes Problem bei dem ich alleine nicht weiterkomme. Ich möchte von einem Server Logfiles, interne mailbfr-Backups und noch ein paar andere Sachen mit rsync backuppen. Bevor ich das ganze auf den echten Servern implementier dacht ich probierste das ganze zuerst mal aus. Weil sowas funktioniert ja nie auf Anhieb
Ich habe zu Hause auf dem Client, der das Skript ausführt und auf dem Testserver den root-Benutzer aktiviert. Auf dem Client habe ich ein RSA Schlüsselpaar (mit Passwort) erstellt und den Public Key auf dem Server zu den authorized-keys hinzugefügt. Beim ersten mal einloggen via ssh kam ein Popup das mich nach dem Passwort für den key fragte und mich selbiges im OS X Schlüsselbund speichern ließ. Seitdem kommt keine Passwortabfrage mehr und passwortloser Login ist möglich. Soweit funktioniert alles wie es sollte.

Um den Rsync-Befehl zu automatisieren habe ich einen LaunchDaemon erstellt, der folgendes Skript startet:

#! /bin/sh
# sleep 60
say I am starting the script to sync the two folders!

# Einträge in ein simples Logfile zum debuggen um zu sehen welcher User das Script ausführt
date >> /Volumes/Macintosh_HD/Logfile.txt
id >> /Volumes/Macintosh_HD/Logfile.txt
echo \\n >> /Volumes/Macintosh_HD/Logfile.txt

# Der rsync-Befehl
rsync -r --delete -e "ssh -i /var/root/.ssh/id_rsa" [email protected]:/Volumes/Macintosh_HD/syncSource/ /Volumes/Macintosh_HD/syncDest/

Wenn ich das Skript manuell über das Terminal ausführe kommt die Ansage wie gewünscht, im Logfile scheint auf, dass root das Skript ausführt und die Ordner werden gesynct. Also alles wie es soll.
Wenn launchd das Skript startet kommt auch die Ansage, das Logfile zeigt mir, dass auch hier root der ausführende Benutzer ist, aber es kommt zu keinem Sync.
Die Konsole schreibt:

01.02.10 23:59:18 ich.rysncremote.launchd[874] Permission denied, please try again. 
01.02.10 23:59:18 ich.rysncremote.launchd[874] Permission denied, please try again. 
01.02.10 23:59:18 ich.rysncremote.launchd[874] Received disconnect from 192.168.1.2: 2: Too many authentication failures for root 
01.02.10 23:59:18 ich.rysncremote.launchd[874] rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
01.02.10 23:59:18 ich.rysncremote.launchd[874] rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-35.2/rsync/io.c(452) [receiver=2.6.9] 
01.02.10 23:59:18 com.apple.launchd[1] (msiller.rysncremote.launchd[874]) Exited with exit code: 255

Das ist für mich nicht ganz nachvollziehbar, weil: 1. Das Schlüsselpaar funktioniert, 2. Das Skript wird auch wenn es launchd startet als richtiger Benutzer ausgeführt.

Ich muss allerdings zugeben, dass ich die Launen von launchd nicht ganz durchschaue.

Ich wäre für Tips mehr als dankbar.

Freundliche Grüße,
Silmor.

 

[pepi]

1. Root User wieder deaktivieren, braucht kein Mensch und ist ein enormes Sicherheitsrisiko!
2. Per Launchd kann das Ding nicht auf den Schlüsselbund zugreifen, Du mußt meines Wissens nach einen SSH Key ohne Passwort verwenden.
3. Dein SSH Command ist unnötig komplex. Leg' Dir eine ~/.ssh_config an und schreibe die SSH Parameter dort hin wo sie hingehören, aber nicht auf die Commandline. Dann kannst Du rsync foo Quelle Ziel verwenden wobei foo der Nickname Deiner SSH Verbindung ist.
Gruß Pepi

 

[silmor]

1. Den habe ich nur angelegt um ihm einen eigenen Schlüsselbund zu verschaffen, wenn der root aber eh nicht drauf zugreifen kann werde ich ihn wieder deaktivieren.
2. OK das wird wohl der Fehler sein.
3. Das Skript ist ja vorerst nur eine Krücke um das ganze in einer Testumgebung auszuprobieren, deswegen auch nicht sehr stylisch. Trotzdem Danke für den Tipp. Ist sicherlich sinnvoll die ~/.sshd_config anzulegen um die Befehle einerseits zu kürzen und andererseits wenn es mal zu einem Serverwechsel kommt einfach die zentrale Config zu ändern und die Skripte womöglich unverändert weiterzuverwenden.
Freundliche Grüße,
Silmor.

 

[FrankR]

Nur ein kleiner Hinweis: Zur Sicherheit würde ich bei nicht passhphrase-geschützten Schlüsseln in der authorized_keys das Kommando, dass der Schlüssel ausführen darf beschranken. Alternativ kann man mit "from" auch noch die Gegenseite etwas einschränken (hilft natürlich nichts gegen IP Spoofing etc.).

Die Config Datei für den ssh client heisst übrigens ~/.ssh/config.