Hi Liste, ich habe hier ein (IMHO) interessantes Problem. Während ich die Hilfe-Mail schrieb, kam ich dann auf die Lösung - die ich der Liste nicht vorenthalten wollte, da es mit sicherheit ein häufüges Sicherheitsproblem ist Daten sicher zu kopieren (uups ;-)). Szenario: Rechner-A (CLIENT) soll Daten zyklisch per rsync nach Rechner-B (SERVER mit Backup, Raid, etc...) kopieren (SYNCen). Weiterhin soll es "sicher" sein - z.B. auch via Internet laufen. Folgendes ist "standard" und (hoffentlich) einfach. - auf CLIENT und SERVER je einen Backup-Benutzer mit den entsprechenden Rechten auf den Verzeichnissen - public-key Authentifizierung von backup@CLIENT nach backup@SERVER via (open)SSH (-> man ssh-keygen) - public-key per keychain "permanent" laden [1] - rsync in Crontab des users backup läuft, holt sich den private key via keychain, macht rsync [2] Mit "forced-commands" läßt sich der Befehl der mit einem bestimmten SSH-Private/Public-Key möglich ist festlegen (hier nur rsync). Das Problem war (für mich) nur welchen Befehl man angeben muss. Bei rsync ist das nicht offensichtlich, da rsync selber die Ssh- verbindung aufbaut. Die Lösung war (im Nachhinein) auch nicht schwer. auf SERVER den ssh-Daemon einmal mit "sshd -d" im Debug -Modus starten, dann kommt als Debug-Ausgabe auf CLIENT der "SSH_ORIGINAL_COMMAND" zurück. ---- SSH_ORIGINAL_COMMAND=rsync --server -logDtprc . /Backup/ ---- Dieses Kommando ist vollständig (mit Parametern und Pfad) in die ".ssh/authorized_keys2" vor dem schlüssel angzugeben. Der Begin von authorized_keys2 sieht folgender massen aus: ----- command="rsync --server -logDtprc . /Backup/" ssh-dss AAAA... ----- geholfen hat mir auch ein Artikel im Linux-Magazin [3] gruss Johannes Goecke PS: Ist es eigendlich erwünscht, wenn ich ein Problem auch mal ohne Hilfe lösen konnte, gleich eine Zusammenfassung für Archiv zu schreiben oder soll sowas besser ins lug-wiki? PPS: Wenn nicht dann wenigstens eine Frage: Habe ich ausser Keychain und den Private-key im RAM noch eine weitere Sicherheitslücke oder ist dies (nach menschlichem ermessen) Dicht? [1] http://www.gentoo.org/projects/keychain.html keychain ist ein Schlüsselmanager, der den ssh-agent startet und den privaten schlüssel im RAM hält. Beim neu-einloggen werden die Environment-Variablen wieder auf den Agenten gesetzt, so daß man nur noch einmal (nach dem booten des Rechners) die Passphrase des ssh-keys eingeben muss. Eine prinzipielle Schwachstelle ist (bes. wenn man dem Benutzer root nicht traut) den Private-Key permanent im RAM geladen zu haben, aber alles andere (unverschlüsselter key / unverschlüsselte Verbindung, ??) ist IMHO noch unsicherer. [2] eintrag in die Crontab des Backup-Users auf CLIENT ---- 42 * * * * source ~backup/.ssh-agent-client ; /usr/bin/rsync -e ssh -a -c /files-to-Backup/* backup@server:/Backup/ ---- [3] http://www.linux-magazin.de/Artikel/ausgabe/2002/09/ssh/ssh.html