Ein System zum Verteilen von öffentlichen SSH-Schlüsseln

Wir haben viele verschiedene Systeme, die von mehreren Personen verwaltet werden. Wir haben uns für die Verwendung der SSH-Authentifizierung mit öffentlichem Schlüssel für den Zugriff auf diese Systeme entschieden. Dies funktioniert hervorragend, da keine administrativen Kontokennwörter verwaltet oder freigegeben werden müssen, keine Kennwörter für die verschiedenen Systeme gespeichert werden müssen (nur die Passphrase für Ihren privaten Schlüssel) und keine Interaktion (Eingabe eines Kennworts) mit jedem Remote-Befehl erforderlich ist .

Das Problem ist, dass die auf den Systemen installierten öffentlichen Schlüssel irgendwie verwaltet werden müssen. Leute kommen und gehen, Schlüssel können kompromittiert werden, Verantwortlichkeiten ändern sich (eine Person, die berechtigt ist, ein System heute zu betreten, kann berechtigt sein, morgen auf ein anderes zuzugreifen). Derzeit bearbeiten wir die ~ / .ssh / authorized_keys-Dateien für jedes Konto, für das dies erforderlich ist, manuell. Dies ist jedoch sehr aufwändig und fehleranfällig.

Gibt es ein fertiges Tool zum Verwalten öffentlicher Schlüssel in einem solchen Szenario? Haben Sie eigene Lösungen? Oder ist die ganze Idee, Systeme auf diese Weise zu verwalten, fehlerhaft?

Wie bereits von Pulegium erwähnt, kann jede generische Konfigurationsverwaltungssoftware wie Puppet , Chef , Bcfg2 oder Cfengine diese Aufgabe erfüllen.

Da die Datei authorized_keys nicht so kompliziert ist, können Sie diese Datei auch mit rsync oder einem (D) SCM wie git oder hg verwalten. Sie haben die "Master" -Datei auf einem Ihrer Server und bedienen sie über rsync / git / hg /…. Auf jedem anderen Server führen Sie einen Cron-Job aus, der die Masterkopie (falls sie geändert wurde) regelmäßig abruft und an den richtigen lokalen Speicherort kopiert. Das würde sogar mit reinem HTTP oder FTP funktionieren.

Die Quintessenz lautet: Halten Sie eine "Masterkopie" Ihrer authorized_keys-Datei bereit und aktualisieren Sie diese. Lassen Sie die "Clients" (die Computer, auf denen sich die aktuelle Datei "authorized_keys" befinden sollte) sie von Ihrem Master-Server abrufen und lokal bereitstellen.

Für OpenSSH ist ein Patch verfügbar, mit dem öffentliche Schlüssel von einem LDAP-Server verwendet werden können. Dies ist jedoch nur dann sinnvoll, wenn Ihre Authentifizierungs- / Kontoüberprüfungen auch für diesen LDAP-Server durchgeführt werden (so ist meine Umgebung eingerichtet). Außerdem ist es nur so sicher wie Ihre LDAP-Konfiguration (Sie möchten also SSL verwenden und Schlüssel überprüfen).

Unter http://code.google.com/p/openssh-lpk/ finden Sie den Patch und weitere Details. Ich kenne kein Betriebssystem, das standardmäßig mit diesem Patch geliefert wird, aber wenn Sie FreeBSD verwenden, ist es ein optionaler Patch, wenn Sie OpenSSH von Ports aus verwenden.

Ich verwende eine sehr einfache Lösung, die das gleiche mit Firewall-Regeln macht

Beispieldatei hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribute.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

Das ist die ganze Magie :-)

Ich checke gerade SSH KeyDB aus . Es soll genau das tun, Rollen, Server und Benutzer verwalten, Benutzerschlüssel verteilen, Hostschlüssel sammeln usw. Es hat sogar so genannte "Standorte".

Ich habe noch nicht alles ausgearbeitet und bin mir nicht sicher, ob es vollständig funktioniert. Der Code ist jedoch in Python und scheint ziemlich verwaltbar zu sein, daher sollte es nicht zu schwierig sein, ihn abzuwischen und zum Laufen zu bringen.

Ich bin mir nicht sicher, was Sie mit vielen meinen, und ich weiß auch nicht, ob Sie bereit sind, Änderungen vorzunehmen, aber Kerberos ist der Droide, nach dem Sie suchen. Das löst Ihre Probleme auf elegante Weise und authentifiziert sowohl Menschen als auch Maschinen.

Sie haben zwei (in der Regel drei) verschiedene Probleme, die Sie lösen möchten:

• Authentifizierung (Wer bist du?)
• Autorisierung (Dürfen Sie auf diesen Server zugreifen?)
• Audit (Was haben Sie gemacht?)

Die Authentifizierung mit öffentlichen Schlüsseln ist manchmal in Ordnung, es wird jedoch überhaupt nicht auf die Autorisierung eingegangen. Ich mag Public-Key-Authentifizierung nicht, da es sehr leicht ist, Kompromisse einzugehen (insbesondere intern), es sei denn, Sie verfügen über einige gute Steuerelemente.

Hier kommen Lösungen wie Kerberos ins Spiel. In der Windows-Welt löst Active Directory dieses Problem. In der Unix-Welt gibt es eine Fülle von Wahlmöglichkeiten, was sowohl gut als auch schlecht ist.

Ich würde das Red Hat FreeIPA- Projekt ausprobieren , bei dem es sich um ein Softwarepaket handelt, mit dem es einfach ist, ein AD-ähnliches Kerberos / LDAP / DNS-System schnell zum Laufen zu bringen.

Sie können Bcfg2 mit Bcfg2-Konten verteilen authorized_keys. Als zusätzlichen Bonus können Sie Benutzer und Gruppen steuern.

Bcfg2 ermöglicht die schmerzfreie Wartung auch /etc/ssh/ssh_known_hostsmit SSHbase .

Es gibt auch SKM