Zentrales Managementsystem für SSH-Schlüssel?

27

Wir möchten auf die schlüsselbasierte Verwaltung von SSH-Anmeldungen umsteigen und fragen uns, ob es Schlüsselverwaltungssysteme gibt, mit denen wir die Zugriffsschlüssel weltweit zentral verwalten können.

Das System sollte idealerweise die Ausgabe von Schlüsseln pro Client und deren Widerruf ermöglichen, um die Server-Computer-Schlüssel sofort zu aktualisieren.

Kennt jemand ein solches System, entweder kommerziell oder Open Source?

HINWEIS: Zur Verdeutlichung benötigen wir die Schlüsselverwaltung für eine große Anzahl von Cloud-Servern (EC2-ähnlich) und eine kleine Anzahl von Dienstbenutzern. Ich denke, LDAP + -Patch könnte der richtige Weg sein.

ssh cloud keys

— SyRenity
quelle

7

Ist es nur ich, der denkt, dass "private-keys and cloud" wie "drink and drive" sind? Beide machen Spaß, gehen aber nie zusammen.

— mailq

1

"Cloud" ist wahrscheinlich das falsche Wort - es klingt nach zentralisierter Authentifizierung mit weltweiter Konsistenz.

— Voretaq7

Hallo. Genau das, wonach wir suchen.

— SyRenity 20.10.11

Ich habe mit diesem Problem mit einigen Hybridumgebungen meiner Kunden zu kämpfen. Es stellt sich auch die Frage, wo das OPenLDAP oder die Zentralinstanz in einer Cloud-Bereitstellung aufbewahrt werden soll. Ich habe ausgerechnet webmin als Schlüsselverwaltungstool und als Kochbuch verwendet, um Schlüssel mit Knoten zu synchronisieren.

— Tom H

Userify deckt ab, wonach Sie suchen (siehe serverfault.com/questions/647797/… )

— Jamieson Becker

8

Dafür gibt es viele Möglichkeiten. Die Speicherung von LDAP-Schlüsseln wurde einige Male erwähnt, und das habe ich getan, und es funktioniert, soweit es geht. LDAP hat jedoch seine eigenen Management-Besonderheiten, die einiges an Lernen erfordern.

Ich bin ein großer Fan von einfachen, robusten Servern mit minimalen externen Netzwerkabhängigkeiten für einfache Dinge wie die Authentifizierung von Administratoren. Daher neige ich zu einer weitaus robusteren Strategie für die Verteilung von SSH-Schlüsseln. Der öffentliche Schlüssel eines jeden Benutzers wird im Konfigurationsverwaltungssystem gespeichert. Überall, wo sich die Person anmelden muss, wird ihr Schlüssel hinzugefügt. Das Konfigurationssystem kann auch Schlüssel entfernen, die nicht angegeben wurden. Wenn also jemand das System verlässt oder deren Schlüssel sich ändert, müssen Sie lediglich die Schlüsselkonfiguration entfernen und beim nächsten Start des Konfigurationssystems den Schlüssel entfernen.

— womble
quelle

Dieser Ansatz ist sicherlich ein guter, und als Womble weist darauf hin , es den Vorteil, dass Server GOTs aufbleiben und (und zugänglich) im Falle LDAP läuft ab - Jedes LDAP gestütztes System sollte (ich wage zu sagen muss ) zumin Mindestens ein Benutzer, dessen Tasten wie von Womble beschrieben herausgedrückt werden. Der Nachteil ist, dass Sie einen Konfigurationslauf durchführen müssen, um Benutzer zu de-autorisieren. Für ein "Notfallkonto" mit nur wenigen autorisierten Benutzern kein Problem. Größeres Problem für eine große Anzahl von Konten :)

— voretaq7

1

Sie müssen ohnehin eine Möglichkeit haben, Massen-Konfigurationsläufe auszulösen, daher sollte es keine große Sache sein, dies für eine Kontoänderung zu tun.

— womble

Ich bin damit einverstanden, leider Geschäftsanforderungen / Mentalitäten nicht: Paranoia an vielen Orten (meine eingeschlossen) diktiert , dass config - Schübe passieren außerhalb der Arbeitszeiten , aber neue Mitarbeiter / leaving Personal jederzeit passieren kann: - /

— voretaq7

1

Sie sind also froh, an einem Geschäftstag Dinge kaputt zu lassen, nur weil Sie tagsüber keinen Konfigurations-Push ausführen können? Nur weil es üblich ist, heißt das nicht, dass es nicht dumm ist.

— womble

2

Hallo. Eine gute Idee wäre es also, Puppet dafür zu verwenden?

— SyRenity

23

Schlüsselpaare sollten vom Benutzer generiert werden.

Der Benutzer behält die private Hälfte - Sie sollten sie niemals sehen. Wenn Sie den privaten Schlüssel einer Person in einem Formular haben, in dem Sie ihn lesen / verwenden können, machen Sie Sicherheitsfehler.

Die öffentliche Hälfte erhalten Sie (durch einen beliebigen Mechanismus: Webformular, E-Mail, Gib-es-mir-auf-eine-CD), um zentralisiert zu werden, wie Sie möchten. An einigen Stellen werden die öffentlichen Schlüssel in LDAP gespeichert. Andere verteilen authorized_keysDateien mithilfe ihres Bereitstellungssystems.

In meiner Umgebung geben Benutzer, die Shell-Zugriff benötigen, mir ihre öffentlichen Schlüssel. Diese Schlüssel werden unserem LDAP-System hinzugefügt und sshdkonsultieren die öffentlichen Schlüssel, die für jeden Benutzer aufgelistet sind, um sie mithilfe des LDAP-Patches für öffentliche Schlüssel zu authentifizieren .
Wenn jemand einen zusätzlichen Schlüssel hinzufügen oder einen vorhandenen Schlüssel widerrufen muss, teilt er dies einem Administrator mit, und wir kümmern uns darum. Wenn wir skalieren, werde ich schließlich ein System implementieren, mit dem Benutzer ihre eigenen öffentlichen Schlüssel drehen können.

Jeder unserer Standorte verfügt über ein Paar LDAP-Server, die mit der LDAP-Replikation mit unserem Master synchronisiert sind und die Daten an jedem Standort konsistent (und zugänglich) halten.

Alles, was ich beschrieben habe, kann mit Open-Source-Software durchgeführt werden. Es gibt auch kommerzielle Produkte, die dasselbe tun.
Sie müssen die verfügbaren Optionen genauer untersuchen und entscheiden, welche für Ihre Umgebung am besten geeignet sind. Wenn Sie weitere (spezifischere) Fragen haben, können wir wahrscheinlich hilfreicher sein.

— voretaq7
quelle

Sie schlagen also vor, eine LDAP-Infrastruktur mit gepatchtem OpenSSH zu verwenden, die mit LDAP funktioniert? Wie gut skaliert dies in der Produktion? Kann es eine große Anzahl von Maschinen unterstützen? Wir müssen nur eine kleine Anzahl von Servicebenutzern unterstützen.

— SyRenity

1

@SyRenity: LDAP unterstützt Replikation und Clustering, sodass es sehr gut skaliert

— Hubert Kario,

@SyRenity Theoretisch können Sie eine unbegrenzte Anzahl von Computern an einer unbegrenzten Anzahl von Standorten unterstützen (denken Sie an "Really Large Active Directory Deployment" - AD ist im Grunde LDAP mit modischem Zubehör). Für Servicebenutzer ist mein Vorschlag, sie in Ihrer Umgebung zu standardisieren /etc/passwdund standardisierte /etc/groupDateien und Dateien zu veröffentlichen (ermöglicht den normalen Betrieb der Computer und das Starten / Ausführen der zugehörigen Services, auch wenn LDAP nicht verfügbar ist)

— voretaq7 20.10.11

@ voretaq7 Bedeutet dies, dass die Dienstbenutzer getrennt von LDAP über das Konfigurationsmanagement verwaltet werden?

— SyRenity

@SyRenity yes - und vor allem für die Dienste verfügbar, die sie verwenden, wenn LDAP nicht verfügbar ist . Planen Sie für Ausfälle oder Sie werden Katastrophen erleben.

— Voretaq7

9

Schlüsselpaare sollten nur auf dem Computer jedes Benutzers generiert werden. Private Schlüssel werden aus einem bestimmten Grund als solche bezeichnet.

Trotzdem konnte ich einen Anwendungsfall für eine Art zentrales Repository der öffentlichen Schlüssel der Benutzer sehen. Eine Möglichkeit wäre, öffentliche Schlüssel in OpenLDAP zu speichern - neuere Versionen von OpenSSH können Schlüssel aus LDAP auslesen.

— EEAA
quelle

2

Befindet sich das LDAP-Public-Key-Zeug jetzt in OpenSSH? Ich kenne nur den LPK-Patch (für den ich mich verbürgen kann - er funktioniert hervorragend). Auch +1, um private Schlüssel privat zu halten.

— Voretaq7

@ voretaq7 Ich schätze, ich habe gehört, dass es in der Hauptlinie verschmolzen wird, aber ich habe das selbst noch nicht verifiziert. Wir haben gemeinsam genutzte Home-Verzeichnisse über NFS, sodass wir uns um unsere Schlüsselverteilung kümmern.

— EEAA

+1 Nun, das wusste ich nicht. das würde mir ein paar Ärger ersparen. Das ist jetzt auf meiner Liste der Dinge, in die ich schauen muss.

— Tom H

1

Ich weiß, dass dies eine etwas ältere Frage ist, aber Google gibt sie ziemlich hoch zurück, wenn Sie nach so etwas suchen.

Für diejenigen von uns, die eine andere Lösung als LDAP suchen, habe ich gerade das Projekt "SKM" gefunden: https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
quelle

1

Es gibt viele großartige kommerzielle und Open-Source-Lösungen wie Userify [1] (wo ich arbeite), Universal Key Manager [2], SSH Key Box [3] usw. Es hängt davon ab, was Sie brauchen und ob Sie es tun Auf der Suche nach etwas, das die Verwaltung zentralisiert und gleichzeitig den Betrieb dezentralisiert (damit Ihre Server nicht auf eine zentrale Berechtigung angewiesen sind, um sich anzumelden). In diesem Fall können Sie sich möglicherweise nicht bei einem Ihrer Server anmelden, z LDAP-Server ist ausgefallen!)

Siehe auch diese Slant-Diskussion:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Jamieson Becker
quelle