Wie rolle ich über SSH-Host-Schlüssel?


17

Ich versuche, meinen SSH-Server von 2048-Bit-RSA-Schlüsseln auf größere Schlüssel zu aktualisieren, da empfohlen wird, 2048-Bit-Schlüssel bald auslaufen zu lassen.

Ich habe einen neuen Schlüssel generiert und ihn dann wie folgt zur sshd-Konfiguration hinzugefügt:

HostKey / etc / ssh / ssh_host_rsa_key             (alter 2k-Bit-Schlüssel zuerst) 
HostKey / etc / ssh / ssh_host_rsa4096_key         (neuer größerer Schlüssel 2. )

Nach dem Neustart sshdschicke ich eine Nachricht an den Host. Ich bekomme keine Warnung, dass sich die Identifikation geändert hat, aber die neue wird auch nicht zwischengespeichert ~/.ssh/known_hosts. Wenn ich die Zeilen in die entgegengesetzte Reihenfolge bringe, erhalte ich die Warnung, dass sich die Identifikation geändert hat. Wenn ich einen ed25519-Schlüssel hinzufüge, fügt der Client unabhängig von der Reihenfolge, in der ich ihn eingebe, den neuen Schlüssel nicht zur bekannten Hosts-Datei hinzu.

Dies scheint ein Rollover des SSH-Hostschlüssels unmöglich zu machen - es ist jedoch schwer zu glauben, dass dies tatsächlich der Fall ist, wenn man bedenkt, dass die Sicherheit routinemäßig ein Upgrade der Schlüssel erfordert.

Ich weiß, dass Sie den Schlüssel einfach austauschen können. Dann muss jeder Client ausgeführt werden ssh-keygen -R, um den alten Schlüssel zu entfernen. Anschließend muss der neue Schlüssel manuell überprüft und akzeptiert werden alle kunden. Nicht zu vergessen, wenn Sie die Clients nicht verwalten, ist die Wahrscheinlichkeit sehr hoch, dass sie den Host-Schlüssel nicht überprüfen und stattdessen einfach Y drücken. Wenn Sie also versuchen, die Sicherheit zu verbessern, werden Sie wahrscheinlich tatsächlich für den Benutzer geöffnet. stattdessen die mittleren Angriffe.

Gibt es eine Möglichkeit, SSH-Hostschlüssel-Upgrades zum Laufen zu bringen? Das heißt, Clients sollten den neuen sichereren Schlüssel erlernen (und hoffentlich auch den veralteten Schlüssel nicht erlernen). Und ohne den Host-Schlüssel zu geben, änderte sich die Man-in-the-Middle-Warnung.


Bitte haben Sie einen Blick auf diese . Es bietet zwar keine Lösung für das, was Sie gerade wollen, kann Ihnen jedoch helfen, Ihre Endziele in Zukunft zu erreichen.
rda

Antworten:


14

Die Host-Key-Rotation wird seit OpenSSH 6.8 unterstützt (Client und Server bieten in dieser Version zusätzliche Unterstützung).

Der Prozess sollte also so funktionieren:

  • Generieren Sie neue Schlüssel und fügen Sie sie mit der Option HostKey newkey(nach den vorhandenen) zum hinzu/etc/ssh/sshd_config
  • Neustart sshd
  • Die Clients müssen UpdateHostKeys yesin ihrer Konfiguration eingerichtet werden (entweder global oder pro Host)
  • Die verbindenden Clients werden alle neuen Schlüssel abholen
  • Nach einiger Zeit (Monate?) Können Sie die alten Schlüssel vom entfernen sshd_configund neu startensshd
  • Die Clients (die während der Übergangsphase verbunden waren) haben bereits die neuen Schlüssel (die alten werden nicht entfernt, was hier das einzige Problem ist) und zeigen die MitM-Angriffswarnung nicht an.

Die neuen Clients können die neuen Schlüssel abholen. Diese Funktion ist standardmäßig nicht aktiviert, wahrscheinlich, weil sie ziemlich neu ist und bald einige Sicherheitsaspekte aufwies. Aber heutzutage sollte es in Ordnung sein, es zu benutzen.


-4

sshd benutze immer die erste Zeile, also lösche sie und starte sshd neu.


1
... was dazu führt, dass der beängstigende Hostschlüssel die Warnung geändert hat. Versuchen Sie dies zu vermeiden, indem Sie die Clients den neuen Schlüssel lernen lassen (und den alten auslaufen lassen).
Derobert

Du hast recht. Sie können nicht zwei verschiedene Schlüssel gleichzeitig verwenden. ssl ist nicht tls. Es gibt keine Funktion zum Hinzufügen von Schlüsseln, die sich nur ändert.
Ipor Sircer

4
Es ist weder SSL noch TLS. Das Protokoll unterstützt mehrere Host-Schlüssel. Früher verfügten beispielsweise alle über RSA- und DSA-Schlüssel. Jetzt sind es normalerweise ED25519-, ECDSA- und RSA-Schlüssel.
Derobert
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.