Sicherheit automatische ssh authentifizierung für Backupserver

[dhartmann]

Hi Prolinux Forum,

ich habe da mal eine Frage ob meine Überlegungen für die automatische ssh authentifizierung
für einen Backupserver richtig sind. Mir stellt sich die Frage ob es bei mehreren zu sichernden Systemen sinnvoller ist, die privaten Schlüssel auf den Backup Server zu lassen oder auf den einzelnen Quellservern.

$ ssh-keygen -t rsa

$ ssh-copy-id -i ~/.ssh/id_rsa.pub USERNAME@QUELLSERVER


Auszug aus meinem kleinem HOWTO


# Anmerkung zur Sicherheit der automatischen ssh Authentifizierung
#
# In diesem Beispiel verbindet sich der Backupserver mit den Quellserver, von dem die Daten gesichert werden sollen.
# Auf dem Backup Server muss demnach auch der private Schluessel für die automatische ssh Verbindung zum Quellserver liegen.
# Wenn der Backupserver mehrere Quellserver sichern soll ist es besser wenn die privaten Schlüssel auf den Quellservern liegen und
# sich jeweils mit einem anderen privaten Schluessel zum Backupserver verbinden. Denn, wenn alle privaten Schluessel auf dem Backup Server liegen, hat
# der Angreifer, wenn er Zugang zum Backupserver erlangt, automatisch auch Zugang zu allen Quellservern.
# Wenn jedoch unterschiedliche private Schluessel auf den Quellservern existieren, und einer der Quellserver geknackt wird,
# dann hat der Angreifer nur Zugang zum geknackten Quellserver und zum Backupserver, aber nicht gleich auch Zugang zu allen anderen Quellservern.

Kann man das so sagen?

[Marco Gerber]

guten Tag

Mir stellt sich die Frage ob es bei mehreren zu sichernden Systemen sinnvoller ist, die privaten Schlüssel auf den Backup Server zu lassen oder auf den einzelnen Quellservern.

Eigentlich beantwortest du dir diese Frage gleich weiter unten selbst.
Wenn es praktisch akzeptabel ist, solltest du es vermeiden, alle privaten Schluessel an einem zentralen Ort zu lagern. Ergo sollte der Backupserver gar nicht die Moeglichkeit haben, sich mit den Quellservern zu verbinden. Eine solche Aktion erscheint mir aufgrund der Aufgabe eines Backupservers als sehr fragwuerdig.

Viel besser ist es in diesem konkreten Fall, wenn die Quellserver sich mit ihrem einzigen private key beim Backupserver anmelden.

Und, jeder Quellserver hat seinen eigenen Keyring.

# Wenn jedoch unterschiedliche private Schluessel auf den Quellservern existieren, und einer der Quellserver geknackt wird,
# dann hat der Angreifer nur Zugang zum geknackten Quellserver und zum Backupserver, aber nicht gleich auch Zugang zu allen anderen Quellservern.

Dieser Schluss erscheint mir noch nicht fertig gedacht zu sein.
Worin genau soll der Vorteil mehrerer private keys deine Meinung nach genau liegen?

hth

Marco

[dhartmann]

Hi Marco, danke erstmal für deine Antwort.

# Worin genau soll der Vorteil mehrerer private keys deine Meinung nach genau liegen?

Ich hab das glaub ich etwas missverstanden, es ist ja immer ein unterschiedlicher KEYRING auf jedem Quellserver, nicht nur der private key

Ist es möglich durch die public keys von den Quellservern die ja auf dem Backupserver liegen, auf einen anderen Quellserver zuzugreifen? Solange der private Key, von dem noch nicht geknackten Quellserver,dem backup server nicht bekannt ist sollte das nicht gehen oder?

Naj muss noch n bischen weiter lesen . . .

[Marco Gerber]

guten Tag

Ist es möglich durch die public keys von den Quellservern die ja auf dem Backupserver liegen, auf einen anderen Quellserver zuzugreifen?

Wenn du das nachfolgende beachtest, ist dieser Fall ausgeschlossen.


Ich empfehle dir, von der Idee, dass ein Backupserver eine Verbindung mit einem Quellserver aufbaut zu verwerfen.

Das Problem liegt auf der Hand. Wenn der Backupserver kompromitiert wurde, sind auch die Quellserver nicht mehr sicher.

Die sicherste Variante besteht darin, dass der Backupserver fuer jeden Client (Quellserver) ein eigenes Keypair generiert (one way).

Hier ist entscheidend, wie hoch der Grad der Automatisierung der Verteilung gewaehlt wird.
Es gibt zwei Situationen.
Entweder der Client bekommt seinen Key so zugestellt wie du im ersten Post geschrieben hast, oder er muss ihn sich explizit beim Backupserver holen (schlussendlich beim Administrator).

Je nach Philosophie kann man die eine oder andere Version bevorzugen. Dazu lassen sich keine verallgemeinernden Ratschlaege geben.

Naj muss noch n bischen weiter lesen . . .

Immer eine gute Idee.
Was liest du?

hth

Marco

[dhartmann]

gelesen habe ich bisher einige howtos und die man page, ist aber nicht sehr befriedigend

http://rootwiki.unixfreunde.de/index.ph ... _via_Rsync
http://www.linuxwiki.de/rsync
http://www.heinlein-support.de/web/wissen/rsync-backup/
http://www.linuxnetmag.com/de/issue8/m8rsync1.html
http://www.drcoffee.de/deutsch/projekte ... rsync.html

und noch ein paar andere...

Ich finde die Infos zu rsync sind irgendwie nicht ganz vollständig, oder ich habe noch nicht den richtigen suchmechanismus gefunden. Z.B habe ich in der doku nicht gefunden dass in der 'INCLUDE' Datei, wenn man ein Verzeichnis rekursiv sichern will, zwei Sternchen angeben muss, also

# include file
/Verzeichnis/*
/Verzeichnis/**

Leider verstehe ich die inkrementelle funktion noch nicht richtig.
Die Hardlink Option ist schon klar, aber wie sieht es übers Netzwerk aus? Wenn ich die Daten über ssh rüberschaufel können hardlinks ja nicht mehr funktionieren oder? Und für welchen einsatz ist eigentlich die --backup Option gedacht? Wie funktioniert der --backup algorythmus? --backup hört sich gut an;)

Derzeit sichere ich die Daten als fullbackup für eine Woche über cron
Ich habe auch die komplexen skripte mit backup.daily und backu.rotate etc.. im Netz gesehen. Ist mir aber zu komplex für eine Zeile code;)


# 7 Tage voll Backup
# Montag
0 0 * * 1 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Montag > /opt/rsync/Montag.log 2>&1

# Dienstag
0 0 * * 2 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Dienstag > /opt/rsync/Dienstag.log 2>&1

# Mittwoch
0 0 * * 3 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Mittwoch > /opt/rsync/Mittwoch.log 2>&1

# Donnerstag
0 0 * * 4 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Donnerstag > /opt/rsync/Donnerstag.log 2>&1

# Freitag
30 10 * * 5 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Freitag > /opt/rsync/Freitag.log 2>&1

# Samstag
0 0 * * 6 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Samstag > /opt/rsync/Samstag.log 2>&1

# Sonntag
0 0 * * 7 root rsync -e ssh -avz --delete --include-from=/opt/rsync/include / user@your-server.de:backup_drive/Sonntag > /opt/rsync/Sonntag.log 2>&1
#