openssh - authorized_keys - rsync

[Johannes Goecke]

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 at CLIENT nach backup at 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 at server:/Backup/
----

[3]
http://www.linux-magazin.de/Artikel/ausgabe/2002/09/ssh/ssh.html