Bestes System zur Verwaltung von SSH-Schlüsseln? [geschlossen]

Ich habe mehrere Client-Computer (z. B. Laptops, Desktops usw.), stelle eine Verbindung zu mehreren von mir verwalteten Servern her und melde mich über SSH an. Ich kann mir mehrere sinnvolle Schemata für die Verwaltung von ssh-Schlüsseln vorstellen und bin gespannt, was andere tun.

Option 1: Ein globales öffentliches / privates Schlüsselpaar.

Ich würde ein öffentliches / privates Schlüsselpaar generieren und den privaten Schlüssel auf jedem Client-Computer und den öffentlichen Schlüssel auf jedem Server-Computer ablegen.

Option 2: Ein Schlüsselpaar pro Server.

Ich würde ein Schlüsselpaar auf jedem Servercomputer generieren und jeden privaten Schlüssel auf meinen Clientcomputern ablegen.

Option 3: Ein Schlüsselpaar pro Client-Computer.

Jeder Client-Computer verfügt über einen eindeutigen privaten Schlüssel, und jeder Server-Computer verfügt über die öffentlichen Schlüssel für jeden Client-Computer, von dem aus eine Verbindung hergestellt werden soll.

Option 4: Ein Schlüsselpaar pro Client / Server-Paar

Völlig über Bord?

Welches davon ist das Beste? Gibt es noch andere Möglichkeiten? Nach welchen Kriterien bewerten Sie die richtige Konfiguration?

Ich verwende Option 3: Ein Schlüsselpaar pro Client-Computer , was für mich am sinnvollsten ist. Hier sind einige der Gründe:

• Wenn ein Client kompromittiert ist, muss dieser Schlüssel (und nur dieser Schlüssel) von den Servern entfernt werden.
• Es ist flexibel genug, um zu entscheiden, auf was ich von wo aus zugreifen kann, ohne allen Clients pauschalen Zugriff auf alle Server zu gewähren.
• Sehr angenehm. Es gibt nur 1 Schlüssel für ssh-add, keine Verwirrung.
• Einfache Einrichtung und Verwaltung über Option 4

Option 4 ist schön, aber es ist einfach zu viel Arbeit. Option 3 bringt Ihnen 98% mit viel weniger Aufwand.

Ich verwende eine etwas kompliziertere, aber sehr vielseitige Lösung, da ich die SSH-Identitätsschlüssel, die für meine Heimnetzwerkserver, Büroserver, Clientnetzwerkserver und andere verschiedene Systeme, auf denen ich Konten habe, verwendet werden, in gewisser Weise trennen möchte.

Nun, da ich fast ausschließlich von Linux-Workstations aus arbeite, habe ich einen USB-Stick, der mit LUKS-Verschlüsselung eingerichtet wird. Mein X11-Fenstermanager und der HAL-Daemon erkennen das LUKS-verschlüsselte Laufwerk und fordern die Entschlüsselungs-Passphrase an, wenn es eingefügt und versucht wird montiert werden. Durch das Speichern auf einem verschlüsselten Laufwerk, wie ich es tue, speichere ich meine SSH-Schlüssel nie auf einer Workstation.

Ich habe dann folgende Konfiguration in meiner ~/.ssh/configDatei:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

Das % d wird übersetzt die Home - Verzeichnis von OpenSSH zu sein und in dem ~ / .ssh Verzeichnis habe ich erstellt keys.d als symbolischen Link auf den Verzeichnispfad auf dem verschlüsselten USB - Laufwerk , wenn es richtig montiert.

Der % l- Ausdruck wird in den Hostnamen des lokalen Clientcomputers übersetzt, und % u wird in den Benutzernamen des lokalen Clients übersetzt.

Diese Konfiguration ermöglicht es SSH, mit drei verschiedenen Ausdrücken nach einem Schlüssel zu suchen. Wenn beispielsweise der Benutzername jdoemeines lokalen Clients und der Name meines lokalen Clientcomputers lauten examplehost, wird in der folgenden Reihenfolge gesucht, bis ein Schlüssel gefunden wird, der sowohl vorhanden ist als auch vom Remoteserver akzeptiert wurde.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Sie können sogar den % r- Ausdruck verwenden, um nach einem Schlüssel zu suchen, der für den Benutzernamen des Remoteservers oder für % h für den Hostnamen des Remoteservers spezifisch ist, genau wie % u und % l verwendet wurden.

Update: Jetzt benutze ich den GnuPG gpg-Agent mit ssh-Agent-Kompatibilität, um nur den Authentifizierungsschlüssel von meiner OpenPGP v2-Smartcard zu lesen und zu verwenden.

Ich würde beide Ihrer Option 1s eliminieren (von denen ich vermute, dass eine Option 2 sein sollte ;-), da private Schlüssel vertrauliche Daten sind und es sinnvoll ist, sie an so wenigen Orten wie möglich aufzubewahren. Ich persönlich würde niemals einen privaten Schlüssel von einem Computer auf einen anderen kopieren (oder sogar von einer Datei auf eine andere auf demselben Computer), außer vielleicht, um Backups zu erstellen. Im Gegensatz zu den meisten Verschlüsselungsschlüsseln ist der Verlust eines SSH-Schlüssels nicht das Ende der Welt (erstellen Sie einfach einen neuen, Sie verlieren keine Daten).

Option 3 und verwenden Sie so etwas wie Puppet, um die Schlüsselverwaltung zu erledigen.

Option 3.

Auf diese Weise können Sie auch steuern, auf welche Server ein Client zugreifen kann. Wenn z. B. Client X Zugriff auf Server A und B, aber C oder D benötigt, kopieren Sie den öffentlichen Schlüssel nur auf diese Hosts.