Debian: Sicherung via cronjob (shellscript) und ssh key

[converge]

Hallo zusammen,

ich bin derzeit dabei, meinen Server auf einen anderen Server zu sichern. Die Backups werden dabei per Cronjob und Shellscript gesteuert. Bisher werden die Datenbanken gedumpt und die Verzeichnisse archiviert und schließlich in einem dafür vorgesehenen Ordner abgelegt. Nun möchte ich allerdings einen weiteren Server dazu schalten und die Daten via SCP auf diesen übertragen.

Das ganze führt auch schon zum gewünschten Ergebnis, allerdings muss ich beim ssh key die Passphrase weglassen, da diese beim Login ja abgefragt wird. Ist dies unsicher? Kann die Passphrase weggelassen werden? Oder gibt es sogar eine Möglichkeit, die Passphrase im Shellscript, welches die Verbindung herstellt mit zu übergeben?

Danke für eure Tipps

 

[Roger Wilco]

Das ganze führt auch schon zum gewünschten Ergebnis, allerdings muss ich beim ssh key die Passphrase weglassen, da diese beim Login ja abgefragt wird. Ist dies unsicher?

Ein ungesicherter kryptographischer Schlüssel ist natürlich weniger sicher, als ein gesicherter kryptographischer Schlüssel. Wenn du keine Passphrase nutzt und ein Angeifer die Datei kopiert, hat er ohne weitere Anstrengung den gleichen Zugang zu dem Zielsystem wie du selbst (bzw. dein Skript).

Um das Risiko zu vermindern kannst du z. B. einen SSH-Agent verwenden, der für eine Session den "entsicherten" Schlüssel vorhält, und die Kommandos, die auf dem Zielsystem mit dem Schlüssel ausgeführt werden dürfen, minimieren (siehe dazu die Manpage sshd(8), Abschnitt "AuthorizedKeys File Format").

Die Passphrase für den kryptographischen Schlüssel im Klartext in ein Skript zu packen ist übrigens auch unsicher und bringt dir im Fall des Falles nur ein warmes Gefühl in der Magengegend ein.

 

[Deleted member 11740]

Ich hab dabei auch immer ein ungutes Gefühl. Wird der Backupserver kompromittiert, dann hast du pech.

Unter anderem gibt es z.B. Keychain von Gentoo. Das Paket gibt es auch in Debian. Sieh es dir mal an: http://www.gentoo.de/doc/de/keychain-guide.xml

 

[converge]

Ich hab dabei auch immer ein ungutes Gefühl. Wird der Backupserver kompromittiert, dann hast du pech.

Na, das würde ich ja vermeiden können, in dem ich die Richtung umdrehe. Ich "schiebe" die Backups vom Live-Server auf den Backup-Server. Dann müssen sie erst den Live-Server entern. Wenn Sie das schaffen, ist mir der Backup-Server auch egal

 

[Roger Wilco]

Dann müssen sie erst den Live-Server entern. Wenn Sie das schaffen, ist mir der Backup-Server auch egal

Mal ganz doof gefragt: Wozu machst du dann überhaupt Backups?

 

[Schokobecher]

Mal ganz doof gefragt: Wozu machst du dann überhaupt Backups?

Hardware Ausfall?
Ich traue meinem Raid auch nur so weit, wie ich den Controller werfen kann.
Außerdem hat man dann ein angenehmes Gefühl, jederzeit seine Dateien bereit zu haben.

 

[Deleted member 11740]

...
Ich "schiebe" die Backups vom Live-Server auf den Backup-Server...

Wenn der Server wirklich nur für Backups da ist, kannst du diesen ja ohne jegliche Dienste bis auf SSH laufen lassen. Firewall dementsprechend einrichten und ggf. den SSH-Server nur über ein VPN zugänglich machen. Der Backupserver kann sich dann vom gefährdeten Live-Server die Backups selber ziehen. Wenn dann jemand was vom Backupserver will, muss er sich erst per VPN einwählen und sich dann auch noch per SSH einloggen. Das VPN natürlich dann auch so einrichten, dass der Traffic nicht geroutet wird.

 

[wstuermer]

Wenn der Server wirklich nur für Backups da ist, kannst du diesen ja ohne jegliche Dienste bis auf SSH laufen lassen.

Wenn der Backup-Server nur für Backups da ist, dann soll der sich gefälligst die Daten vom Live-Server ziehen und ich habe auch den sshd gespart - und somit gar keine lauschenden Dienste mehr.

 

[Deleted member 11740]

Gut, wenn du mir dann noch erklärst wie du ohne KVM auf den Server zugreifst, dann wäre ich dir sehr dankbar oder hat dein Server ein 56K-Modem über das du dich dann einloggst? Schließt du deine Haustür auch ab und schmeißt danach den Schlüssel weg? Am besten noch zu schweißen. Nicht jeder hat zugriff auf eine KVM und nicht jeder hat den Server im Nebenzimmer stehen. Nicht immer von sich selbst auf andere schließen.

 

[siradlib]

Wenn der Backup-Server nur für Backups da ist, dann soll der sich gefälligst die Daten vom Live-Server ziehen und ich habe auch den sshd gespart - und somit gar keine lauschenden Dienste mehr.

Du meinst, der Backup-Server zieht sich die Daten per scp, richtig?
Aber brauche ich auf dem Backup-Server nicht trotzdem einen sshd zum Einloggen?

 

[Deleted member 11740]

Wenn Rsync oder SCP vom Backupserver aus gestartet wird, benötigt man keinen sshd. Wenn es umgekehrt laufen soll, schon. Anders sieht es dann mit der Administration aus. Manche Massenhoster bieten sogar den Zugang über eine KVM mit an.

 

[Whistler]

Oftmals haben Rootserver eine serielle Notfallkonsole. Z.B. bei Strato ist das Standard und kostet (im Gegensatz zu KVM) auch nichts.
Damit ist der SSHD dann wirklich entbehrlich bzw. kann auf Accounts beschränkt werden, die nur Lesezugriff haben (für ein Backup reicht das aus). Zu Wartungszwecken wird dann per serieller Konsole der Vollzugriff freigeschaltet.

In einem solchen Szenario muß der Angreifer dann schon zwei Hürden überwinden: den (hoffentlich) gut gesicherten Konsolenserver des Providers und das Login in den eigentlichen Server.

 

[Deleted member 11740]

Ich war früher mal Stratokunde und habe die serielle Konsole nur selten verwendet. Wenn man sie aber mal benötigt, weiß man sie zu schätzen. Das hat mir oftmals Zeit gespart, wenn ich selbst einen neuen Kernel kompiliert habe und auf Fehlersuche war.

Da ich bis jetzt nie einen Backupserver benötigt habe, kam es mir auch nie in den Sinn auf sshd zu verzichten. Die meisten Einbrüche kommen durch andere Dienste zustande und eben nicht ssh. Oftmals ist auch der Admin selbst das schwächste Glied in der Kette.

Man sollte aber nicht davon ausgehen, dass Grundsätzlich eine andere Möglichkeit für den Zugang außer über SSH zur Verfügung steht.