Methode zum lokalen Veralten des SSH-Schlüsselpaars


10

Ich benutze meine SSH-Schlüssel für eine Weile. Ich denke darüber nach, mein SSH-Schlüsselpaar auf eine stärkere Verschlüsselung zu aktualisieren, und ich kenne nicht alle Geräte, auf denen meine Schlüssel registriert sind.

Ist es möglich, einen SSH-Schlüssel lokal zu "verwerfen" , damit ich eine Warnung erhalte, wenn ich mich mit einem veralteten SSH-Schlüssel authentifiziere?


Wenn Sie schon dabei sind, würde ich vorschlagen, dass Sie nicht mehr denselben SSH-Schlüssel für mehrere Hosts verwenden. Es erhöht unnötig die Angriffsfläche sowie den Wert dieses Schlüssels im Falle eines Verstoßes. Verwenden Sie stattdessen einen Schlüssel für jeden Host, zu dem Sie eine Verbindung herstellen. Idealerweise verwenden Sie einen Schlüssel für jeden Client und Server Paar (aber diese Skalen schlecht , wenn Sie viele Client - Systeme müssen viele Server verbinden). Ich mag es auch, die Schlüssel mit dem Generierungsdatum im Kommentar oder Schlüsselnamen zu versehen, damit ich verfolgen kann, wie alt sie sind. Richten Sie dann alle 6 bis 24 Monate eine wiederkehrende Erinnerung in Ihrem Kalender ein, um sie zu erneuern.
ein CVn

@ MichaelKjörling Ich bin mit dem ersten Teil Ihres Vorschlags nicht einverstanden. Das Generieren vieler Schlüsselpaare, bei denen alle privaten Schlüssel mit denselben Berechtigungen auf demselben Computer gespeichert sind, bietet keine wesentlichen Sicherheitsverbesserungen. Wenn man kompromittiert wird, sind höchstwahrscheinlich auch die anderen kompromittiert. In diesem Fall bedeutet das Vorhandensein vieler Schlüsselpaare nur, dass das Drehen dieser Schlüsselpaare mehr Arbeit erfordert, sobald Sie einen Grund für die Generierung eines neuen Schlüsselpaars sehen. Der Teil über das Hinzufügen eines Generierungsdatums zum Kommentar ist ein guter Rat (ich wünschte, ich ssh-keygenwürde das standardmäßig tun).
Kasperd

@kasperd Du machst einen guten Punkt. Ich nehme an, wie immer hängt es sehr stark von Ihrem Bedrohungsmodell ab. Ich vermute, ich habe implizit angenommen, dass die Schlüssel unterschiedliche Passphrasen haben würden. Ich kann sehen, dass dies bei einer großen Anzahl von Schlüsseln möglicherweise nicht immer praktikabel ist, es sei denn, Sie möchten dem Mix einen Kennwortmanager hinzufügen. Es erlaubt jedoch etwas, das dem, was das OP beschreibt, sehr nahe kommt, da ein Schlüssel sehr leicht "veraltet" werden kann, ohne andere Verbindungen zu beeinträchtigen. Ich vermute am Ende, es ist eine Frage des persönlichen Geschmacks.
Ein CVn

Antworten:


9

Ich kenne keine Möglichkeit, so etwas zu tun, aber ich kann sehen, wie nützlich es wäre. Ich würde gerne aufhören, den veralteten Schlüssel meinem SSH-Agenten hinzuzufügen. Auf diese Weise muss ich jedes Mal, wenn es verwendet wird, die Passphrase erneut eingeben. Wenn es so etwas wie "ugh, noch eine, die repariert werden muss" ist, wird es mich jedes Mal daran erinnern, dass ich meinen Schlüssel auch auf dieser Maschine drehen muss.


In dieser Hinsicht kann es nützlich sein (abhängig von Distribution / DE), die Datei in ein anderes Verzeichnis zu verschieben. Seahorse verwendet beispielsweise alle Schlüssel ~/. sshautomatisch.
Guntbert

1
Alles, was das tut, muss niedergebrannt werden. Dies bedeutet, dass in dem Moment, in dem Sie mehr als sechs Schlüssel haben (ich habe ein paar Dutzend), die Authentifizierung aufgrund zu vieler Fehler fehlschlägt (jeder Schlüssel, der präsentiert und abgelehnt wird, zählt für die Anzahl der Fehler).
Womble

5

Sie können den alten SSH-Schlüssel an einen nicht standardmäßigen Speicherort verschieben (z. B. ~ / .ssh / deprecated_id_rsa) und dann unter ~ / .ssh / id_rsa einen neuen SSH-Schlüssel mit Ihren gewünschten Eigenschaften erstellen

Auf diese Weise steht Ihnen bei Bedarf immer noch Ihr veralteter Schlüssel zur Verfügung ssh -i ~/.ssh/deprecated_id_rsa ..., Sie verwenden jedoch standardmäßig Ihren neuen Schlüssel.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.