Ist Ihre SSH-Hostschlüsselrotation bereit?

Ein SSH-Hostschlüssel sollte nach Ihrem Zeitplan wechseln, wenn Clients seinem Ersatz bereits vertrauen. Erfahren Entwickler erst durch die rote Warnung im Terminal von der Rotation, ist der Plan schon gescheitert. Die Warnung kann nicht erklären, ob sich der Server berechtigt geändert hat oder jemand die Verbindung abfängt. Eine eilige Aufforderung, eine Zeile aus known_hosts zu löschen, vernichtet die Belege für diese Entscheidung.

Eine sichere Rotation hat vier getrennte Schritte: alten und neuen Fingerprint über einen vertrauenswürdigen Kanal veröffentlichen, beide Schlüssel lange genug anbieten, damit Clients den neuen lernen, den alten in einem festgelegten Fenster entfernen und nachweisen, dass Clients die ausgemusterte Identität ablehnen. Ich habe Teams die Serverarbeit richtig erledigen und ihren Entwicklern dennoch die schlechteste Gewohnheit beibringen sehen: die Hostprüfung als Hindernis zu behandeln. Der sichere Weg muss vor der Warnung zum normalen Weg werden.

Hostidentität und Benutzerauthentifizierung sind getrennt

Ein Hostschlüssel belegt, welcher SSH-Server geantwortet hat; ein Benutzerschlüssel belegt, wer sich anmelden will. Die Rotation des einen ändert den anderen nicht. Der Unterschied klingt einfach, doch Einsatzanweisungen vermischen oft authorized_keys, persönliche SSH-Schlüssel, Hostzertifikate und /etc/ssh/ssh_host_* unter der vagen Anweisung, „SSH-Schlüssel zu rotieren“.

RFC 4253 ordnet die Serverauthentifizierung dem Transport-Handshake zu. Der Server signiert den Austausch-Hash mit seinem privaten Hostschlüssel, der Client prüft den öffentlichen Schlüssel anhand einer vertrauenswürdigen Quelle wie known_hosts, einer Host-Zertifizierungsstelle oder authentifizierten SSHFP-Einträgen. Passwörter, Benutzerzertifikate und öffentliche Benutzerschlüssel folgen später. Prüft der Client den Server nicht mehr, kann ein Entwickler einem Betrüger vollkommen gültige Anmeldedaten überreichen.

Deshalb ist die Warnung über einen geänderten Host absichtlich streng. Sie meldet gebrochene Kontinuität: Der eingegebene Name präsentiert eine andere Identität. Geplanter Austausch, neu erstellte virtuelle Maschine, falsch gerichteter Load Balancer, DNS-Manipulation und aktives Abfangen können in diesem Moment gleich aussehen. Der Client kennt Ihren Change-Request nicht.

Schreiben Sie den Umfang auf, bevor Sie etwas erzeugen. Erfassen Sie jeden Hostnamen und Alias, Sonderport, direkt in Skripten notierte Adresse, Bastion-Pfad, CI-Runner, Deployment-Agent und jede gemeinsame GlobalKnownHostsFile. [host]:port ist ein anderer known-hosts-Name als host; Aliasse können das kanonische Ziel verdecken. Eine Rotation für git.example.net, die git.internal vergisst, wirkt sporadisch, obwohl beide Namen dieselbe Maschine erreichen.

Inventarisieren Sie außerdem jeden angebotenen Hostschlüsselalgorithmus. Ein Server kann Ed25519-, ECDSA- und RSA-Hostschlüssel gleichzeitig besitzen. OpenSSH handelt mit dem Client einen Algorithmus aus, daher können zwei Entwickler am selben daemon verschiedene öffentliche Schlüssel fixieren. Nur den auf Ihrem Laptop beobachteten Schlüssel zu wechseln, definiert nicht die vollständige Identitätsmenge. Verwenden Sie die eingerichteten HostKey-Einträge und geprüften öffentlichen Dateien als verbindliches Inventar und vergleichen Sie es mit der tatsächlichen Aushandlung jeder unterstützten Clientgruppe.

Veröffentlichen Sie beide Fingerprints vor der Serveränderung

Veröffentlichen Sie aktuellen und neuen Fingerprint, solange der aktuelle Schlüssel noch Verkehr bedient. Der Publikationskanal darf sein Vertrauen nicht vom zu ändernden SSH-Host beziehen. Ein signiertes Betriebs-Repository, eine authentifizierte interne Statusseite, verwaltete Gerätekonfiguration oder eine getrennt administrierte DNSSEC-Zone eignen sich. Eine Nachricht aus derselben möglicherweise abgefangenen SSH-Sitzung eignet sich nicht.

Erzeugen Sie Fingerprints aus öffentlichen Schlüsseldateien auf einer vertrauenswürdigen Verwaltungsmaschine, nicht durch Abfrage des Produktionsnetzes. OpenSSH zeigt standardmäßig SHA-256-Fingerprints. Befehl und Ausgabeform:

$ ssh-keygen -lf ssh_host_ed25519_key.pub -E sha256
256 SHA256:<base64-fingerprint> host.example.net (ED25519)

Veröffentlichen Sie mehr als den kurzen Digest. Geben Sie für jede Identität Hostname und Port, Algorithmus, SHA-256-Fingerprint, Status (current, new oder retired), erste Nutzung, Ausmusterung und Genehmiger an. Nennen Sie die Zeitzone. Listen Sie Aliasse mit gemeinsamem Schlüssel. Präsentieren verschiedene Knoten hinter einem Namen absichtlich verschiedene Schlüssel, veröffentlichen Sie die gesamte zulässige Menge samt Begründung.

Ein brauchbarer Eintrag sieht so aus:

Host: build.example.net:22
Algorithm: ssh-ed25519
Current: SHA256:<old-fingerprint>
New: SHA256:<new-fingerprint>
Overlap begins: 2026-08-10 15:00 UTC
Old key removed: 2026-08-17 15:00 UTC
Old key marked revoked: 2026-08-17 15:30 UTC
Owner: Platform operations

Die Daten sind Beispiele, die Reihenfolge nicht. Eine Veröffentlichung nach der Serveränderung macht aus geplanter Arbeit eine ungeplante Vertrauensentscheidung. Nur den neuen Wert zu zeigen, verhindert den Vergleich mit einer vorhandenen Fixierung. Lassen Sie den alten Eintrag als ausgemustert sichtbar, damit Untersuchungen veraltete Maschinen und unerwartete Wiederverwendung erkennen.

Fingerprints sind öffentliche Kennungen, keine Geheimnisse. Der private Hostschlüssel bleibt auf dem Server geschützt, doch öffentlicher Schlüssel und Fingerprint sollten so breit verteilt sein, dass die Prüfung nicht von einem verfügbaren Administrator abhängt. Behandeln Sie die Genehmigung als Sicherheitsänderung: Zwei Quelldateien mit demselben Fingerprint sind stärker als ein Screenshot im Chat.

Eine Überlappung überträgt den Ersatz sicher

Bieten Sie alten und neuen Hostschlüssel gemeinsam an, bevor Sie den alten entfernen. Während der Überlappung authentifiziert ein bekannter Client den Server mit dem alten vertrauenswürdigen Schlüssel und lernt den zusätzlichen über OpenSSHs Erweiterung [email protected]. Die Kontinuität stammt vom alten Schlüssel; der neue kommt daher nicht als unbestätigte Behauptung.

Das OpenSSH-Handbuch ssh_config beschreibt UpdateHostKeys ausdrücklich als Hilfe für eine gleitende Rotation und nennt wichtige Grenzen. Der Client akzeptiert weitere Schlüssel nur nach Authentifizierung durch einen bereits vertrauenswürdigen oder ausdrücklich angenommenen einfachen Schlüssel über eine Benutzerdatei. Nach einem Hostzertifikat oder bei ausschließlicher Nutzung einer globalen Datei funktioniert dieser Weg nicht. Der Standard kann auch abgeschaltet werden, wenn der Benutzer UserKnownHostsFile überschreibt oder VerifyHostKeyDNS aktiviert.

Verlassen Sie sich nicht auf den Standard. Prüfen Sie die wirksame Clientkonfiguration:

$ ssh -G build.example.net | grep -E '^(updatehostkeys|userknownhostsfile|stricthostkeychecking) '
stricthostkeychecking ask
updatehostkeys true
userknownhostsfile ~/.ssh/known_hosts ~/.ssh/known_hosts2

Bewahren Sie auf dem Server getrennte private Dateien auf und deklarieren Sie beide. Die Pfade sind Beispiele:

HostKey /etc/ssh/ssh_host_ed25519_key_old
HostKey /etc/ssh/ssh_host_ed25519_key_new

Führen Sie vor dem Neuladen sshd -t aus. Laut Handbuch prüft dieser Modus Konfiguration und Schlüsselzustand und findet unlesbare Dateien oder ungültige Einstellungen vor dem Einlesen. Laden Sie neu, statt aktive Sitzungen zu beenden, sofern der Service-Manager nichts anderes vorgibt. Verbinden Sie anschließend einen sauberen Testclient, der nur dem alten Schlüssel vertraut, und untersuchen Sie nach einer authentifizierten Sitzung seine isolierte Datei.

Mehrere konfigurierte Schlüssel garantieren nicht, dass alle Clients denselben aushandeln. Algorithmuspräferenz, Clientalter, angepasstes HostKeyAlgorithms, Zertifikate und globale Speicher beeinflussen das Ergebnis. Halten Sie die Überlappung mindestens einen normalen Verbindungszyklus jeder Clientklasse aufrecht, nicht eine beliebige Stundenzahl. Wöchentlich verbundene Laptops brauchen ein anderes Fenster als CI-Worker mit minütlichen Verbindungen.

Messen Sie die Verbreitung, ohne vorzugeben, alle persönlichen known_hosts zu sehen. Verwaltete Clients können das Vorhandensein des neuen öffentlichen Schlüssels melden. Bei anderen können Sie Verbindungen nach Version erfassen, sofern die Datenschutzregeln es erlauben, einen klaren Prüfbefehl veröffentlichen und die Überlappung über die normale Nutzung erhalten. Stille beweist keine Verbreitung.

Das Änderungsfenster braucht Zustände und Abbruchbedingungen

Ein Änderungsfenster sollte beobachtbare Zustände, Verantwortliche und Rückkehrbedingungen definieren. „Um 15 Uhr rotieren“ sagt nichts über Überlappung, Clientbereitschaft oder den Zeitpunkt des Verbots der alten Identität. Setzen Sie den Vertrauensübergang auf dieselbe Zeitleiste wie das Deployment.

Verwenden Sie fünf Tore:

1. Veröffentlichung abgeschlossen: Unabhängige Prüfer reproduzieren alle Fingerprints aus genehmigten Dateien.
2. Überlappung aktiv: Der Server bietet beide Identitäten, besteht sshd -t, und saubere Clients authentifizieren sich mit der alten, während sie die neue lernen.
3. Bereitschaft erreicht: Verwaltete Speicher enthalten den Ersatz, Tests decken Systeme und Routen ab, der Support hat die exakten Fingerprints.
4. Umstellung abgeschlossen: Der Server bietet den alten privaten Schlüssel nicht mehr, neue Sitzungen bestehen strenge Prüfungen, kein unerwarteter Knoten präsentiert ihn.
5. Sperre belegt: Ein Test-Endpunkt mit der alten Identität wird abgelehnt, und der ausgemusterte Fingerprint bleibt als gesperrt veröffentlicht.

Geben Sie einer Person die Befugnis zum Abbruch. Stoppen Sie bei einem unveröffentlichten Schlüssel, einem Knoten außerhalb des Inventars, einem unterstützten Client ohne Ersatz oder wenn eine Rückkehr einen als kompromittiert geltenden Schlüssel verlangt. Eine gewöhnliche Rotation kann während der Überlappung zurückkehren; bei Kompromittierung ist der betroffene Schlüssel kein sicherer Rückweg.

Trennen Sie Service-Rollback und Vertrauens-Rollback. Sie können ein früheres Serverpaket wiederherstellen, ohne die ausgemusterte Identität zurückzubringen. Halten Sie bekannte Konfiguration, Zugriff auf den neuen privaten Schlüssel und Konsole oder Providerzugang bereit. Ist SSH der einzige Weg, SSH zu reparieren, enthält das Fenster eine verborgene einzelne Ausfallstelle.

Berücksichtigen Sie langlebige multiplexierte Sitzungen. Eine OpenSSH-Masterverbindung kann weiterlaufen, während neue Shells den Transport wiederverwenden. Sie führen keinen neuen Schlüsselaustausch durch und bestätigen die Identität nach der Umstellung nicht. Schließen Sie Test-Master bei Bedarf mit ssh -O exit host und lassen Sie Prüfungen neue TCP-Verbindungen aufbauen.

Planen Sie die Ausmusterung genau und halten Sie danach die Kommunikation offen. Rückkehrer aus dem Urlaub besitzen alte Fixierungen. Erwartet wird ein dokumentierter Fehler samt geprüftem Aktualisierungsweg, keine Ausnahme. Der Support vergleicht zuerst Fingerprints, findet den Eintrag mit ssh-keygen -F und ersetzt ihn aus der genehmigten Veröffentlichung.

Proben Sie die Warnung mit einer isolierten Vertrauensdatei

Testen Sie, ohne das echte ~/.ssh/known_hosts zu berühren. Eine isolierte Datei macht jeden Zustand reproduzierbar und verhindert einen Scheinerfolg durch Monate zuvor gelernte Schlüssel. Verwenden Sie einen Staging-Endpunkt, der die Produktionsfolge nachbildet, oder einen temporären sshd auf einem anderen Port mit denselben Beschränkungen.

Erstellen Sie known_hosts.test aus dem genehmigten alten öffentlichen Schlüssel, nicht aus einem Live-Scan. Verbinden Sie sich und fixieren Sie den logischen Namen mit HostKeyAlias:

$ ssh -F /dev/null \
  -o HostKeyAlias=build.example.net \
  -o UserKnownHostsFile=./known_hosts.test \
  -o GlobalKnownHostsFile=/dev/null \
  -o StrictHostKeyChecking=yes \
  -o UpdateHostKeys=yes \
  -p 2222 test-host.example.net true

Der erste Lauf muss mit beiden Schlüsseln gelingen. Prüfen Sie die Datei mit ssh-keygen -F build.example.net -f ./known_hosts.test, bestätigen Sie den genehmigten Ersatz und vergleichen Sie jeden Fingerprint mit der Veröffentlichung. Status null belegt Konnektivität, nicht die Identitätsmenge.

Lassen Sie danach nur den neuen Schlüssel anbieten und öffnen Sie eine neue Verbindung. Sie muss dank des authentifizierten Lernens gelingen. Stellen Sie eine Kopie nur mit der alten Fixierung wieder her und wiederholen Sie: Mit StrictHostKeyChecking=yes muss der Versuch scheitern. Der negative Fall belegt, dass Clients ohne Überlappung stoppen, statt still zu akzeptieren.

Präsentieren Sie schließlich einen fremden Schlüssel. Bewahren Sie Fehlertext und Status für die Anleitung auf. Schwächen Sie den Test nicht, bis er immer gelingt; die Ablehnung ist der Schutz. Stellen Sie sicher, dass Skripte den Status ungleich null weitergeben, statt ihn in Wiederholungen zu verschlucken.

Verwenden Sie nie StrictHostKeyChecking=no als Korrektur. Das aktuelle Handbuch sagt, dass damit bestimmte geänderte Schlüssel fortfahren, während accept-new sie ablehnt. Auch dieses löst die Rotation eines bekannten Namens nicht. Liefern Sie authentifizierte Vertrauensdaten oder nutzen Sie die Überlappung.

Eine Sperre muss ablehnen, nicht nur aufräumen

Das Entfernen des alten privaten Schlüssels vom vorgesehenen Server belegt nur, dass dieser Server ihn nicht mehr anbietet. Sperren heißt, dass Clients den öffentlichen Schlüssel bei erneutem Auftauchen ablehnen, auch auf einem vergessenen Knoten oder bei einem Angreifer mit gestohlenem privaten Schlüssel. Das Löschen der alten known_hosts-Zeile tut das Gegenteil: Es entfernt die Erinnerung an die ausgemusterte Identität.

OpenSSH-Dateien unterstützen @revoked. Ein passender so markierter Schlüssel wird nie angenommen und erzeugt eine Warnung. Verwaltete Flotten können einen globalen Eintrag verteilen, kleinere eine eigene Datei. Verwenden Sie exakt den genehmigten öffentlichen Schlüssel und begrenzen Sie das Namensmuster bewusst:

@revoked build.example.net ssh-ed25519 <old-public-key-data>

Eine Key Revocation List hilft bei größeren Mengen und Zertifikaten. Erzeugen Sie eine Test-KRL aus dem alten Schlüssel und fragen Sie sie ab:

$ ssh-keygen -k -f revoked-hostkeys.krl ssh_host_ed25519_key_old.pub
$ ssh-keygen -Q -f revoked-hostkeys.krl ssh_host_ed25519_key_old.pub
ssh_host_ed25519_key_old.pub (<comment>): REVOKED

Die Abfrage liefert für einen gesperrten Schlüssel einen Status ungleich null; Automatisierung muss ihn bewusst deuten. Konfigurieren Sie RevokedHostKeys, verlangen Sie Ablehnung des alten und Erfolg des neuen Endpunkts. Beide Hälften zählen: Eine ungültige oder unlesbare Datei kann alle Verbindungen blockieren.

ssh-keygen -R host bearbeitet Dateien mit gehashten Namen, sperrt aber nichts. Es entfernt alle Einträge, auch den gültigen Ersatz, und macht die nächste Verbindung erneut zur Vertrauensentscheidung. Nutzen Sie den Befehl nur nach einem Vergleich und fügen Sie danach den genehmigten neuen Schlüssel hinzu. Die Folge aus -R und nicht authentifiziertem ssh-keyscan automatisiert die Aufgabe von Vertrauen.

Bewahren Sie gesperrtes öffentliches Material auf. Einen nicht kompromittierten ausgemusterten privaten Schlüssel können Sie nach Richtlinie vernichten, aber öffentlicher Schlüssel, Fingerprint, Genehmigung und Testergebnis bleiben. Sie identifizieren ein altes Image, das Monate später zurückkehrt.

Automatisierung muss geschlossen scheitern, ohne spröde zu werden

Nicht interaktive Jobs brauchen eine gepflegte Vertrauensquelle, keine abgeschaltete Prüfung. CI-Runner, Deployment-Agenten und autonome Programmieragenten begegnen der Rotation oft zuerst, weil sie laufend kurze Verbindungen öffnen. Enthält ein Image einen Hostschlüssel und niemand pflegt seine Erneuerung, lautet der übliche Notbehelf StrictHostKeyChecking=no. Er verwandelt einen Verfügbarkeitsfehler in ein Authentifizierungsproblem.

Wählen Sie ein Modell pro Klasse: beide genehmigten Schlüssel während der Überlappung ins Image schreiben, eine zentral verwaltete globale Datei einbinden, genehmigte Zeilen per KnownHostsCommand liefern, SSHFP mit DNSSEC prüfen oder einer Host-CA vertrauen. Laut Handbuch ergänzt der Befehl die normalen Dateien und beendet die Verbindung bei einem Fehler. Das ist richtig, verlangt aber einen verfügbaren Vertrauensdienst.

Machen Sie den Batchbetrieb ausdrücklich:

Host build.example.net
    BatchMode yes
    StrictHostKeyChecking yes
    UserKnownHostsFile /etc/company/ssh_known_hosts
    UpdateHostKeys no

UpdateHostKeys no ist hier beabsichtigt. Das Konfigurationsmanagement besitzt die Datei; Änderungen durch kurzlebige Worker erzeugen verlorenen, nicht prüfbaren Zustand. In einer dauerhaften Benutzerdatei kann yes besser passen. Entscheidend ist der Eigentümer der Vertrauensverteilung.

Testen Sie Aliasse, Sprunghosts, direkte IPs und Ports als getrennte Identitäten. ProxyJump authentifiziert weiterhin das Ziel, der Sprunghost hat seine eigene Fixierung. Container und isolierte Agenten können eine schreibgeschützte Datei, ein anderes Binary oder kein Benutzerverzeichnis verwenden. Führen Sie ssh -G target in der echten Umgebung aus.

Trennen Sie bei agentengesteuertem SSH Anmeldedaten und Hostvertrauen. Sallyport führt Aktionen über sp-ssh aus, während SSH-Schlüssel im verschlüsselten Vault bleiben; der Agent erhält die Geheimnisse nicht. Das schützt ihre Verwahrung, ersetzt aber weder eine authentifizierte Hostidentität noch einen getesteten Ablehnungsweg.

Ein Automatisierungsfehler sollte erwarteten und beobachteten Fingerprint nennen, ohne privates Material auszugeben. Wiederholen Sie nicht mit schwächeren Einstellungen. Stoppen Sie den Job, sichern Sie stderr und effektive Konfiguration und geben Sie die Abweichung an den Verantwortlichen.

Wiederholen Sie denselben Test auf einem Wegwerf-Worker ohne Zustand im Home-Verzeichnis. Geben Sie ihm genau das verwaltete Paket, führen Sie den echten Job aus und archivieren Sie ssh -G. So erkennen Sie falschen Erfolg durch eine frühere interaktive Sitzung, die eine nicht deklarierte Datei gefüllt hat.

Entfernen Sie nach der Umstellung den Ersatz aus einer Kopie des Pakets, um den Fehlerweg zu prüfen. Der Job muss vor dem Remotebefehl stoppen und den SSH-Status erhalten. Verteilen Sie den Ersatz und wiederholen Sie. Wandelt das Framework jeden SSH-Fehler in einen Timeout um, beheben Sie das vor dem Fenster, um Identitätsablehnung, Netz und Benutzerfehler zu unterscheiden.

Suchen Sie überbreites Vertrauen. Ein Platzhalter kann einen Schlüssel für viele Namen gültig machen; gemeinsame Hostschlüssel machen Maschinen ununterscheidbar. Beides kann beabsichtigt sein, aber der Rotationsnachweis muss den Umfang nennen. Bevorzugen Sie für verschiedene Identitäten eigene Zeilen und testen Sie den exakten Namen des Jobs.

Fixieren Sie außerdem SSH-Binary und Konfigurationsvertrag autonomer Jobs. Ein Basis-Image-Update kann gleichzeitig mit der Identität Standardwerte ändern. Erfassen Sie vorher und nachher Version, effektive Algorithmen, Datei-Hash und logischen Namen. Damit unterscheiden Sie falschen Server, fehlenden Schlüssel und gescheiterte Aushandlung.

DNS und Zertifikate verändern die Verteilung

SSHFP und Hostzertifikate reduzieren einzelne Fixierungen, beseitigen die Rotationsplanung aber nicht. Sie verschieben den stabilen Vertrauensanker. Nutzen Sie sie, wenn Sie diesen besser als Tausende unabhängige Einträge betreiben können.

RFC 4255 verlangt authentifizierte DNS-Daten, bevor einem SSHFP vertraut wird. Praktisch muss DNSSEC vom Client bis zum Eintrag validieren. Ein unsignierter DNS-Eintrag hilft beim Vergleich, stellt aber keine Identität gegen einen Angreifer her. VerifyHostKeyDNS yes vertraut still nur sicheren Treffern.

Veröffentlichen Sie beide SSHFP-Einträge während der Überlappung, warten Sie auf Caches und Resolver und entfernen Sie den alten mit dem privaten Schlüssel. Erzeugen Sie Einträge aus genehmigten Dateien mit ssh-keygen -r hostname -f public_key_file. Prüfen Sie Eintrag und Validierungsstatus über den echten Clientpfad. Eine kurze TTL repariert weder defektes DNSSEC noch einen falschen Wert.

Hostzertifikate erlauben Vertrauen in einen Eintrag wie @cert-authority *.example.net. Ein neuer zertifizierter Schlüssel mit richtigen Principals und Gültigkeit wird unter der bestehenden CA akzeptiert. Das ist für dynamische Flotten sauber, doch die CA hat große Macht. Schützen Sie ihren privaten Schlüssel, begrenzen Sie Ausgaben, protokollieren Sie Seriennummern und Principals und proben Sie ihre Sperre getrennt.

Führen Sie eine CA nicht nur ein, um eine unbequeme Rotation zu vermeiden. Sie bringt Ausstellung, Ablauf, Benennung und eigene Rotation mit. Eine kleine stabile Flotte kann klare Fixierungen gut betreiben; eine große kurzlebige profitiert oft von Zertifikaten.

Dokumentieren Sie, wo Vertrauen beginnt. UpdateHostKeys gilt nicht nach Zertifikatsauthentifizierung, und eine globale Datei lernt nicht über den Benutzermechanismus. Modelle ohne festgelegten Vorrang zu mischen, führt zum Erfolg auf dem Laptop und Fehler in CI.

Schließen Sie mit Belegen ab, die das Fenster überleben

Eine abgeschlossene Rotation belegt, was sich änderte, wer genehmigte, was Clients akzeptierten und ob das Alte abgelehnt wurde. Bewahren Sie öffentliche Schlüssel, reproduzierte Fingerprints, sshd -t-Ergebnis, effektive Konfiguration, Publikationsrevision, Clientmatrix, Zeitpunkte, Sperrdatei und Negativtest auf. Kein privater Schlüssel gehört ins Ticket.

Erfassen Sie nach dem Fenster den echten Zustand. Fragen Sie jeden Knoten über jede Produktionsroute ab und vergleichen Sie ihn mit der genehmigten Menge, wobei Netzsammlung nur eine Beobachtung ist. Vergleichen Sie sie mit der authentifizierten Veröffentlichung. Prüfen Sie Autoscaling-Images und abgeschaltete Reserveknoten; alte Schlüssel kehren oft durch Ersatzkapazität zurück.

Activity journal und Sessions journal in Sallyport können eine manipulationserkennbare Spur der SSH-Aktionen eines Agenten aus einem verschlüsselten, hashverketteten Audit-Log bewahren. sp audit verify prüft diese Kette offline über den Ciphertext und ohne Vault-Schlüssel. Das ergänzt Aktionsbelege, ersetzt aber keine Hostschlüsseltests.

Setzen Sie eine Nachprüfung nach dem Flottenverhalten an. Suchen Sie Clients, die noch am alten Fingerprint scheitern, Knoten mit unerwarteter Identität und Skripte mit Umgehungsoptionen. Entfernen Sie die temporäre Überlappung. Halten Sie die Sperre aufrecht, solange der private Schlüssel in Backups, Images oder unbefugten Kopien überleben kann.

Eine Hostschlüsselwarnung sollte selten und alarmierend bleiben. Gute Rotation unterdrückt sie nicht. Sie organisiert den Vertrauensübergang früh genug, damit erwartete Clients sie nie ignorieren müssen, und weist danach nach, dass sie die zurückkehrende alte Identität weiterhin stoppt.