rsync-Problem

[chrisu]

Hallo.
Ich habe heute nach der Anleitung der FAQ das "Backup- und rsync-System" installiert.
Alles funktioniert prima, nur die Ã?bergabe des Passwortes via "password-file" funktioniert nicht.

Code: Select all

rsync --verbose  --stats --compress --rsh=/usr/bin/ssh --recursive --times --perms --links --delete --password-file=/root/rsync_pwd /backup/* rootserver@backup.server::rootserver_backup

Die Date rsync_pwd besteht im Verzeichnis Root mit den Rechten 600.

Trotzdem werde ich beim Aufruf immer nach dem Passwort gefragt.

Wer weis Rat??

Christoph

[captaincrunch]

Nutze besser SSH's Public-Key-Authverfahren. Das ist ohnehin sicherer.

[chrisu]

Also wenn hier was schnell ist, dann dieses Forum :-)))

Werde es versuchen...

[chrisu]

Irgendwie klappt es doch nicht mit dem Key.
Habe es nach div. hier im Forum befindlichen Tipps und auch nach der Anleitung unter linux-user.de (Answergirl) versucht, bekomme aber trotzdem immer noch die Aufforderung ein Passwort einzugeben.

Gibt es vielleicht irgendwo eine Schritt-für-Schritt Anleitung zum Erstellen des Keys, wo welche ssh-Datei hinkommt bis zum Aufruf von rsync mit ssh??

Dies würde einem Newbi sehr helfen.

Danke

Christoph

[captaincrunch]

Der Answergirl-Artikel ist IMHO die Referenz überhaupt, aber OK.

Wie wär's denn, wenn du uns einmal Schritt für Schritt erläutern würdest, was du getan hast, u.U. sieht man dann einen möglichen Fehler.

[chrisu]

Gerne.

Vielleicht ist aber auch schon das der Fehler: Muss der Key auf dem Server oder Backupsystem erstellt werden und dann auf den andern Rechner übertragen werden??

Christoph

[captaincrunch]

Das kommt ganz darauf an, wie rum du die Daten kopieren willst. ;)

Sofern du das Backup erst lokal machst, und die Daten dann rüberschiebst, würde ich das Schlüsselpaar auf dem normalen Rechner erzeugen, und den öffentlichen auf den Backupserver bringen. Ein Stolperstein dabei : u.U. lauten die Namen der Files, in der der Schlüssel abgelegt wird anders (normalerweise authorized_keys2 für ssh v2 (was ohnehin ausschließlich verwendet werden sollte)).

[chrisu]

Ok, dann mal, wie ich es gemacht habe:

Server= zu sichernder Rechner
zu sicherndes Verzeichnis = /backup

Back-Server= Backupsystem
Sicherungsverzeichnis = /eins/zwei/drei

1. Auf dem Server mit ssh-keygen -r rsa einen Schlüssel erstellt:
- Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/test_rsa
- Enter passphrase (empty for no passphrase): "leer"
- Enter same passphrase again: "leer"

->
- The key fingerprint is:
"der Fingerpring" meine_mail@server.de
- 2 Dateien in /root/.ssh
test_rsa
test_rsa.pub

2. Die Datei test_rsa.pub habe ich in das Verzeichnis /root/.ssh via 2 geöffneter WinSCP geDrag-and-Dropped.

3. Auf dem Back-Server habe ich

Code: Select all

cat ~/.ssh/test_rsa.pub | ssh -v meine_mail@server.de cat - >> ~/.ssh/authorized_keys

aufgerufen.

4. Bei der Frage nach dem Passwort für meine_mail@server.de habe ich nichts eingegeben.

5. Ich versuchte rsync zu starten:

Code: Select all

rsync -avz -e ssh /backup/* rsync@ip-des-Back-Servers:/eins/zwei/drei

6. Es kommt trotzdem die Passwortabfrage

Christoph

[captaincrunch]

Dann leg die Schlüssel auf dem normalen Rechner mit den korrekten Dateinamen (id_rsa) an. ;)

[chrisu]

MUSS es id_rsa sein??
Ich dachte, dies sei ein Patzhalter??

Sonst stimmt mein Vorgehen??

Danke

Christoph

[captaincrunch]

Es muss nicht, aber IMHO wird id_rsa standardmäßig verwendet, ansonsten musst du den Key explizit per Option angeben.

Prinzipiell passt nämlich alles.

[chrisu]

Wenn prinzipiell so alles stimmt, werde ich das heute abend nochmal mit dem Standardnamen versuchen.

Hoffe es klappt.

Gäbe es denn sonst noch eine empfehlenswerte Alternative die Dateien zwischen 2 Servern in einer "sicheren" Weise per Cron zu verschieben??

Vielen Dank für Deine Hilfe

Christoph

[captaincrunch]

Gäbe es denn sonst noch eine empfehlenswerte Alternative die Dateien zwischen 2 Servern in einer "sicheren" Weise per Cron zu verschieben??

Ja, nennt sich lufs, was dir ermöglicht, ein entferntes Filesystem (z.B.) per ssh zu mounten, und du es dann wie ein lokales behandeln kannst.

[chrisu]

Hi Captain,

ich habe es befürchtet, es funktioniert nicht mit dem rsync.
Ich werde weiterhin nach dem Passwort gefragt.

- Ist es denn wirklich richtig, den öffentlichen Schlüssel in das selbsterstellte Verzeichniss .ssh unter /root zu kopieren??
- Muss der Eintrag in die authorized_keys auf dem Server und/oder Back-Server gemacht werden?
- Bei dieser Eintragung

Code: Select all

cat ~/.ssh/test_rsa.pub | ssh -v meine_mail@server.de cat - >> ~/.ssh/authorized_keys

muss ich ja auch

Code: Select all

meine_mail@server.de

angeben. Ich das der rsync-User auf dem Back-Server, oder was?

Sorry, wenn ich nerve, aber ich würde wirklich derne rsync benutzen, da es bei manueller einga des Passwortes wirklich gut funktioniert.

Danke für Deine Hilfe und Geduld!

Christoph

[chrisu]

Hat sich mittlerweile erledigt.
http://projectdream.org/publications/ssh.html
hat geholfen :-)

Christoph

[captaincrunch]

Sorry, wenn ich nerve, aber ich würde wirklich derne rsync benutzen, da es bei manueller einga des Passwortes wirklich gut funktioniert.

Tust du schon nicht, keine Panik. Ich reagiere nur etwas allergisch auf Leute, die sich alles schon fertig "verdaut" vorsetzen lassen wollen, und keine Eigeninitiative zeigen.

Also dann mal los :

- Ist es denn wirklich richtig, den öffentlichen Schlüssel in das selbsterstellte Verzeichniss .ssh unter /root zu kopieren??

Genau das sollte durch den Aufruf von ssh-keygen normalerweise automatisch passieren ?!? Schau dir mal die Rechte des .ssh-Verzeichnisses an, die müssen 600 sein.

- Muss der Eintrag in die authorized_keys auf dem Server und/oder Back-Server gemacht werden?

Sofern du die Daten vom Server zum Backupserver schiebst, also von normalen Server aus den ssh-Aufruf machst, muss der Public-Key in die ~USERNAME/.ssh/authorized_keys2 . Die 2 am Ende ist relativ wichtig, da genau dieses File von ssh in Version 2 erwartet wird. Auch die Rechte dieses .ssh-Verzeichnises sollten 600 sein.

Kleiner Tipp : zum debuggen des ganzen ist die Option -v (bzw. -vv oder -vvv) ein sehr guter Startpunkt, da so genau ausgegeben wird, was im Hintergrund passiert. Dabei fallen einem meiste schon die gröbsten Sachen auf.

Hth

[chrisu]

Vielen Dank für die Antwort,

mittlerweile habe ich es (wie auf der vorigen Seite schon geschrieben) hinbekommen :-)

- Backup läuft
- rsync läuft
- public Key Authentifizeirung läuft

Nur ein Problem gibt es noch.
Ich will eigentlich nur sehr ungern die public Key Authentifizierung ohne Passwort laufen lassen.
Desshalb starte ich per

Code: Select all

eval `ssh-agent`

eine Instanz von ssh-agent
und lese mit

Code: Select all

ssh-add ~/.ssh/id_dsa

den Key ein und gebe dann einmal das Passwort an.
Dieses sollte dann eigentlich im Speicher behalten werden.

Doch leider ist nachts, wenn das Backup und danach die Datenverschiebung via rsync erfolgen soll, das Passwort nicht mehr verfügbar.

Woran kann das liegen?
Unmittelbar nach der Durchführung der obigen Schritte ist ein Verbinden via ssh ohne Probleme und ohne erneute Passworteingabe möglich.

Was würdest du mir empfehlen, wenn ich dann doch die ssh-Authentifizierung OHNE Passworteingabe nutzen müsste?
Welche Vorkehrungen sollte ich treffen, damit das Scheunentor nicht zu weit offen steht?

Danke

Christoph

[captaincrunch]

Woran kann das liegen?

Daran, dass der ssh-agent nicht läuft, wenn das Script gestartet wird, und auch die Informationen aus dem Speicher "gelöscht" werden, nachdem du dich ausgeloggt hast.

Was würdest du mir empfehlen, wenn ich dann doch die ssh-Authentifizierung OHNE Passworteingabe nutzen müsste?

Warum denkst du, dass PubKey-Auth eine Sicherhitslücke darstellt ? Dieses Verfahren allein ist schon extrem sicherer als Passwortauthentifizierung, beides zusammen ist natürlich optimal. "Unsicher" ist PubKey-Auth ohne aber auch nicht.

[chrisu]

Woran kann das liegen?
Daran, dass der ssh-agent nicht läuft, wenn das Script gestartet wird, und auch die Informationen aus dem Speicher "gelöscht" werden, nachdem du dich ausgeloggt hast.

:roll:
Das dachte ich mir. Aber warum???

Was würdest du mir empfehlen, wenn ich dann doch die ssh-Authentifizierung OHNE Passworteingabe nutzen müsste?
Warum denkst du, dass PubKey-Auth eine Sicherhitslücke darstellt ? Dieses Verfahren allein ist schon extrem sicherer als Passwortauthentifizierung, beides zusammen ist natürlich optimal. "Unsicher" ist PubKey-Auth ohne aber auch nicht.

"Auf die Stink hau".
Stimmt. Wieder was gelernt.
Damit sich jemand in meinen Backupserver einloggen kann, braucht er ja dann den Privat-Key, der sich auf meinem Server befindet, richtig??

Also kann ich eigentlich auch ohne Passwort arbeiten. Wie riskant würdest Du das einschätzen im Vergleich zum Variante mit Passwort?

Christoph

[captaincrunch]

Also kann ich eigentlich auch ohne Passwort arbeiten. Wie riskant würdest Du das einschätzen im Vergleich zum Variante mit Passwort?

Diese Frage kann mir dir pauschal leider nicht beantworten, da alles weitere dann von der Wahl der Passphrase abhängt.
Selbst ohne Passphrase ist schon viel wahrscheinlicher, dass ein Angriff über einen Bug / Exploit machbar wäre.