Haben Sie ein System, das SSH-Schlüssel jeden 90. Tag abläuft

Ich habe einen Kunden, der jetzt verlangt, dass wir jedes Passwort jeden 90. Tag ändern, weil er die DSGVO interpretiert. Das ist in Ordnung für das webbasierte System, das wir für sie entwickeln, weil wir diese Regeln einfach implementieren können. Sie verlangen aber auch, dass wir die Passwörter auf unseren SSH-Schlüsseln ändern, die für den Zugriff auf die Server verwendet werden, was nicht in Ordnung ist.

1. Ist es möglich, das Passwort für einen vorhandenen SSH-Schlüssel zu ändern?

2. Wenn nicht, gibt es Tools, die wir verwenden können, um dies zu handhaben? Ich denke:

   ein. Erstellen Sie neue Schlüssel.
   b. Verteilen Sie alle öffentlichen Schlüssel auf vorhandene Server.
   c. Entfernen Sie vorhandene öffentliche Schlüssel.
   d. Alte private Schlüssel archivieren.

   Ich habe hier einige Posts über Puppet gelesen, aber so wie ich es verstehe, sollen sie nur das Problem lösen, die öffentlichen Schlüssel auf die Server zu verteilen und nicht jeden neunten Tag neue Schlüssel zu erstellen. Sollte ich meine Forschungen zu Puppet fortsetzen?

3. Was ist der Community-Standard, wenn es um die Speicherung von Passwörtern und SSH-Schlüsseln geht? Wie machst du das?

Der Kunde irrt sich hier und versteht nicht, wovon er spricht. Das Ändern der Passphrase für einen privaten Schlüssel ist eine sehr schlechte Idee, da sie sehr widersprüchliche Sicherheitseigenschaften aufweist.

Normalerweise denken Benutzer an Passwörter, die sie geändert haben, als "nicht mehr geheim". Sie können zu Wegwerfkennwörtern für Websites mit geringem Wert, Online-Handles / Spitznamen, Pointen für Witze usw. werden, und jedes Papier, auf dem sie geschrieben sind, kann zu Schrott werden, der freigelegt wird.

Bei einer Passphrase, die zum Verschlüsseln eines privaten Schlüssels verwendet wird , funktioniert dies nicht ! Die Passphrase muss für immer geheim gehalten werden, es sei denn, alle mit dem Schlüssel verbundenen Berechtigungen wurden widerrufen (und das Folgende gilt nicht für ssh-Schlüssel, aber wenn die Passphrase für einen Schlüssel bestimmt ist, der nicht nur zum Signieren, sondern zum Empfangen von privaten Nachrichten verwendet wird, dann für immer bedeutet wirklich für immer ). Dies ist auf die Möglichkeit zurückzuführen, dass die verschlüsselte private Schlüsseldatei von einem Angreifer abgerufen oder an einem Ort (wie in einem Backup) gespeichert wurde, an dem sie in Zukunft möglicherweise von einem Angreifer abgerufen wird. Wenn die Passphrase jemals enthüllt wird, ist sie kompromittiert.

In gewisser Weise ist ein privater Schlüssel, der in seiner Lebensdauer N Passwörter durchlaufen hat, 1 / N so sicher, da die Kenntnis eines der letzten Passwörter ausreicht, um den Schlüssel zu gefährden, wenn der Angreifer Zugriff auf die verschlüsselte private Schlüsseldatei hatte .

Nun zurück zu Ihrem Problem.

Wenn sich der Kunde nicht auf dieses Missverständnis mit "ssh-Passwörtern" eingelassen und es aufgegriffen hätte, wäre es das Richtige, es nie zu erwähnen und die Best Practices für die Schlüsselverarbeitung selbst zu befolgen. Aber jetzt müssen Sie wahrscheinlich etwas tun, um sie zufriedenzustellen. Sie könnten versuchen zu erklären, wie Passwörter, die private Schlüssel verschlüsseln, andere Sicherheitseigenschaften aufweisen als Passwörter. Angesichts der Tatsache, dass der Kunde in vielen Punkten Unrecht hat (das Ablaufen von Passwörtern ist im Allgemeinen eine schlechte Idee), bezweifle ich, dass dies funktionieren wird.

Sie haben dann die Aufgabe, ein System zur Verteilung neuer Schlüssel zu automatisieren. Ich rate Ihnen dringend davon ab, ein System zur zentralen Generierung der neuen Schlüssel zu automatisieren, da private Schlüssel niemals zwischen Computern verschoben werden sollten . Stattdessen sollten Sie Prozesse / Erinnerungen / Skripte haben, um es den Mitarbeitern / Auftragnehmern an Ihrer Seite zu erleichtern, die Zugriff benötigen, um neue private Schlüssel zu generieren und die entsprechenden öffentlichen Schlüssel zu veröffentlichen, und über das Verteilungssystem für öffentliche Schlüssel (Puppet oder anderweitig) verfügen Sie verwenden Push diese auf die Systeme, auf die sie zugreifen müssen.

Zusätzlich: Eine Sache, die den Kunden überzeugen könnte, dies zu verwerfen, ist der Hinweis, dass es grundsätzlich keine Möglichkeit gibt, zu erzwingen, dass der neue private Schlüssel eine andere Passphrase hat als der alte oder dass er überhaupt eine Passphrase hat.

Die Antwort auf Ihre erste Frage: "Ist es möglich, das Passwort für einen vorhandenen SSH-Schlüssel zu ändern?" ist ja. Mit openssh ist das so einfach wiessh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

Das Problem ist, dass sich das Kennwort in der privaten Schlüsseldatei befindet. Dies ist ein einfaches Format, das kein Ablaufdatum unterstützt. Ein großer Teil des Konzepts der schlüsselbasierten Authentifizierung in ssh besteht darin, dass der private Schlüssel nicht zentral verwaltet wird, sondern nur auf der Arbeitsstation des Benutzers vorhanden sein sollte, wodurch es nahezu unmöglich wird, eine Kennwortablaufrichtlinie für den privaten Schlüssel durchzusetzen.

Stattdessen: In jeder Umgebung, in der ich war, befand sich die Kennwortrichtlinie auf dem Benutzerkontoobjekt und nicht auf der Methode, die für den Zugriff auf dieses Konto verwendet wurde. Wenn ein Kennwort abgelaufen ist oder ein Konto gesperrt ist, werden alle Zugriffsmethoden einschließlich des SSH-Schlüssels gesperrt.

Fügen Sie die Multi-Faktor-Authentifizierung hinzu, wenn Sie mehr Sicherheit für ein Konto benötigen.

Aber ich bin neugierig, was andere Leute getan haben, um Ihre berechtigten Bedenken auszuräumen.

Mit AuthorizedKeysCommand kann ein Ablaufmechanismus auf der Serverseite implementiert werden. Von der einfachen Überprüfung des Dateizeitstempels bis hin zu etwas Komplizierterem.

Eine Möglichkeit, die möglicherweise ausreicht oder nicht, ist die Verwendung einer SSH-Benutzerzertifizierungsstelle, mit der Sie eine Lebensdauer für den signierten Schlüssel festlegen können. Unabhängig davon, welche Automatisierung Sie für das Signieren von Schlüsseln verwenden, kann das Signieren länger als 90 Tage verweigert werden. Fügen Sie dann den öffentlichen Schlüssel für Ihre Benutzer-CA zu TrustedUserCAKeys in / etc / ssh / sshd_config hinzu und setzen Sie AuthorizedKeysFile auf none.

Sie können ein Tool wie Hashicorp's Vault verwenden, um kurzlebige, signierte SSH-Schlüssel zu erstellen . Jeder Benutzer erhielt jeden Tag (oder so) einen neuen Schlüssel. Sie würden sich bei Vault authentifizieren, um das Zertifikat mit dem zu erhalten, was Sie heute verwenden, beispielsweise mit einem LDAP-Server.

Der Aufwand, dies einzurichten, ist nicht immens, aber meiner Erfahrung nach größer als das, worauf sich @Mark in seinem Kommentar bezog. Sie ersetzen im Grunde genommen ein Problem (ahnungslose Client-Anforderungen) durch ein anderes ( Shard-Management ).

Es ermöglicht jedoch auch ein anderes Szenario, z. B. das einfache Generieren von internen X509-Zertifikaten und das Verwalten von Datenbankkennwörtern, Anwendungsgeheimnissen in einer Textdatei. Sie beurteilen den Aufwand und den ROI.

Beachten Sie auch, dass die Open Source-Version keine DR-Funktionen besitzt (alles andere).

Sie können einen Schlüsselagenten verwenden, der zeitbasierte Einmalpasswörter (TOTP) enthält. Jetzt ändert sich Ihr "Passwort" jede Minute.

_{Alle anderen hier haben jedoch Recht: Das ist albern.}