Kann ein widerrufener SSH-Hostschlüssel Agenten einlassen?

Ein widerrufener SSH-Hostschlüssel muss einen Agenten vor der Benutzerauthentifizierung stoppen, unabhängig vom verwendeten Namen oder der Adresse. Wenn der Test nur einmal den üblichen Hostnamen versucht, beweist er weit weniger, als es scheint. Die SSH-Konfiguration kann mehrere Namen demselben Server zuordnen, ein nicht standardmäßiger Port ändert den Suchbezeichner in known-hosts und ein Client mit Multiplexing kann einen weiteren Kanal ohne neue Hostschlüsselprüfung öffnen.

Behandeln Sie den Widerruf als Eigenschaft der kryptografischen Identität und testen Sie jeden Weg, der diese Identität vorlegen oder wiederverwenden kann. Dazu gehören eine Schlüsselwiderrufsliste, ein sauberer Clientzustand, ausdrücklich benannte Verbindungsvarianten und ein eigenes Verfahren für bestehende Verbindungen. Eine Warnung über einen geänderten Schlüssel ist nützlich, aber sie ist nicht dieselbe Kontrolle.

Der Widerruf muss dem Schlüssel folgen, nicht dem Hostnamen

Ein Hostschlüssel authentifiziert den Server während des SSH-Schlüsselaustauschs. RFC 4253 beschreibt, wie der Client den öffentlichen Hostschlüssel empfängt, seine Zugehörigkeit zum vorgesehenen Server prüft und die Serversignatur über den Austausch verifiziert. Der Widerruf gehört an diese Stelle: Legt der Server einen gesperrten öffentlichen Schlüssel vor, muss der Client ihn ablehnen, bevor er einen Benutzerschlüssel, ein Passwort oder einen entfernten Befehl berücksichtigt.

OpenSSH bietet zwei ähnlich wirkende Mechanismen mit unterschiedlicher Reichweite. Eine mit @revoked beginnende Zeile in einer known-hosts-Datei verbindet ein Hostmuster mit einem widerrufenen Schlüssel. Sie wirkt, wenn der Suchname der Verbindung zu dieser Zeile passt. Ein Alias oder eine andere Adressform kann das Muster verfehlen, obwohl der Server denselben Schlüssel vorlegt. Das OpenSSH-Handbuch für sshd sagt, dass ein passender widerrufener Eintrag nie akzeptiert werden darf, doch die Bedingung des Passens ist entscheidend.

Die Clientoption RevokedHostKeys eignet sich besser für einen Widerruf bei einem Vorfall. Sie verweist auf eine Textdatei mit öffentlichen Schlüsseln oder eine OpenSSH Key Revocation List (KRL). OpenSSH vergleicht die vorgelegte Identität mit dieser Datei, egal ob der Benutzer build-test, build-test.example oder eine IP-Adresse eingibt. Ich verwende @revoked für gezielte known-hosts-Pflege; wenn eine kryptografische Identität überall gesperrt werden muss, verwende ich RevokedHostKeys.

Verwechseln Sie keinen der Mechanismen mit StrictHostKeyChecking=yes. Die strenge Prüfung lehnt unbekannte Hosts und geänderte Schlüssel ab und verhindert damit stilles Vertrauen bei der ersten Verwendung. Sie erklärt einen sonst vertrauenswürdigen Schlüssel nicht für widerrufen. Ein Test, der den alten known-host-Eintrag löscht und einen Fehler wegen eines unbekannten Hosts als Erfolg wertet, hat eine leere Vertrauensdatenbank getestet, keinen Widerruf.

Bauen Sie einen Testhost, den Sie absichtlich beschädigen können

Verwenden Sie einen kurzlebigen SSH-Server mit eigenem Port, Hostschlüssel, Benutzerkonto und Clientverzeichnis. Üben Sie den Widerruf nicht auf einem gemeinsam genutzten Staging-Host. Sie müssen Schlüssel ersetzen, Prozesse stoppen und Kontroll-Sockets schließen können, ohne nach anderen Nutzern fragen zu müssen.

Die folgende Struktur hält die Nachweise in einem Verzeichnis. Der genaue sshd-Pfad und das Berechtigungsmodell hängen vom Betriebssystem ab. Starten Sie den Daemon deshalb in dem Container, der VM oder der Testvorrichtung, die Ihr Team bereits für SSH-Integrationstests nutzt.

set -eu
work="$PWD/ssh-revocation-fixture"
mkdir -p "$work/client" "$work/server"
chmod 700 "$work/client"

ssh-keygen -q -t ed25519 -N '' \
  -C revoked-host-test -f "$work/server/ssh_host_ed25519_key"
ssh-keygen -q -t ed25519 -N '' \
  -C agent-test-user -f "$work/client/id_ed25519"

ssh-keygen -lf "$work/server/ssh_host_ed25519_key.pub"

Der letzte Befehl gibt eine Zeile dieser Form aus:

256 SHA256:<base64-fingerprint> revoked-host-test (ED25519)

Erfassen Sie diesen Fingerabdruck im Testprotokoll. Kopieren Sie nie einen Fingerabdruck aus einem Ticket und nehmen Sie an, die Datei in der Vorrichtung enthalte denselben Schlüssel. Berechnen Sie ihn aus der öffentlichen Schlüsseldatei, die der Testserver tatsächlich lädt.

Konfigurieren Sie den Test-Daemon so, dass er nur diesen Hostschlüssel verwendet. Füllen Sie seine AuthorizedKeysFile mit dem öffentlichen Clientschlüssel, deaktivieren Sie Passwörter und binden Sie ihn an eine Loopback- oder isolierte Adresse. Eine minimale Vorrichtung braucht außerdem eine ausdrückliche PidFile und ausführliche Protokollierung. Das Ziel ist Wiederholbarkeit: ein Listener, eine Hostidentität und ein Authentifizierungsweg.

Lassen Sie vor dem Widerruf eine strenge Verbindung gelingen und führen Sie einen harmlosen Marker wie printf BASELINE_OK aus. Übernehmen Sie den Hostschlüssel in einem authentifizierten Bereitstellungsschritt und nicht mit einem ungeprüften ssh-keyscan über denselben Netzwerkweg, den Sie schützen wollen. ssh-keyscan holt Schlüssel, beweist aber nicht, wer sie geliefert hat.

Nehmen Sie die widerrufene Identität in eine KRL auf

Eine KRL richtet den Test auf den Schlüssel statt auf die Schreibweise des Ziels. Erzeugen Sie sie direkt aus dem von der Vorrichtung geladenen öffentlichen Schlüssel und fragen Sie sie vor jedem Netzwerkversuch ab:

work="$PWD/ssh-revocation-fixture"
ssh-keygen -k -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"

if ssh-keygen -Q -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"; then
  printf '%s\n' 'FAIL: fixture host key is not revoked'
  exit 1
else
  printf '%s\n' 'OK: fixture host key is revoked'
fi

Der umgekehrte Exitstatus führt leicht zu Fehlern. Laut ssh-keygen-Handbuch liefert -Q einen Wert ungleich null, wenn ein abgefragter Schlüssel widerrufen ist oder ein Fehler auftritt; null bedeutet, dass keiner widerrufen ist. Verwerfen Sie stderr nicht und unterscheiden Sie im Testprotokoll eine unlesbare KRL von einem gültigen Treffer.

Binden Sie die Datei nun im weitesten vom Agenten verwendeten Bereich in die Clientkonfiguration ein:

Host *
    BatchMode yes
    StrictHostKeyChecking yes
    UserKnownHostsFile ./ssh-revocation-fixture/client/known_hosts
    RevokedHostKeys ./ssh-revocation-fixture/client/revoked-hosts.krl
    ConnectTimeout 5
    ConnectionAttempts 1

OpenSSH verweigert vorsorglich jede Hostauthentifizierung, wenn die RevokedHostKeys-Datei fehlt oder nicht lesbar ist. Das ist sicherer als ein Ignorieren der Datei, kann aber eine defekte Bereitstellung wie einen gelungenen Widerrufstest aussehen lassen. Die Vorabprüfung belegt, dass die Datei lesbar ist und den vorgesehenen Schlüssel enthält.

Auch eine einfache Textdatei mit einem öffentlichen Schlüssel pro Zeile funktioniert. Die zusätzliche Komplexität einer KRL lohnt sich bei vielen Schlüsseln oder Hostzertifikaten, weil sie einfache Schlüssel, Seriennummern, Zertifikat-IDs oder von einer CA signierte Schlüssel widerrufen kann. Nutzen Sie das einfachste Format, das Ihre Verteilung und Prüfung beherrschen, und testen Sie das tatsächlich bereitgestellte Format.

Ein namensgebundener Marker braucht einen Angriffstest

Behalten Sie einen absichtlich schwachen Fall in der Vorrichtung, um die Notwendigkeit der KRL zu zeigen. Erstellen Sie eine zweite Clientkonfiguration ohne RevokedHostKeys, die nur diesem known-hosts-Eintrag vertraut:

@revoked revoked-lab ssh-ed25519 AAAA...fixture-public-key...

Verbinden Sie sich als revoked-lab und bestätigen Sie, dass OpenSSH den passenden Eintrag ablehnt. Verbinden Sie sich danach als 127.0.0.1 mit demselben Listener und stellen Sie für [127.0.0.1]:2222 einen eigenen vertrauenswürdigen known-host-Eintrag bereit. Gelingt diese Adressform, hat die Vorrichtung die Deckungslücke nachgestellt: Der Schlüssel blieb gleich, aber der Suchname passt nicht mehr zum Widerrufsmarker. Halten Sie diese Demonstration von der Produktionskonfiguration getrennt, denn sie soll die Unzulänglichkeit einer Kontrolle beweisen.

Kopieren Sie nicht den abgekürzten Wert AAAA... aus dem Beispiel. Bauen Sie den Marker aus der echten öffentlichen Schlüsseldatei, damit Algorithmus und base64-Daten exakt stimmen. Ein sicherer Vorrichtungsbefehl kann die Felder für Algorithmus und Schlüssel lesen und Marker sowie Hostmuster voranstellen. Prüfen Sie den Eintrag mit ssh-keygen -F revoked-lab -f known_hosts; wiederholen Sie die Suche für die IP-Adresse und zeigen Sie, dass dort kein Eintrag vorliegt.

Dieser Fehler erklärt, warum eine @revoked-Zeile mit allen bekannten Aliasen brüchig bleibt. Das Inventar ändert sich mit jedem Kurznamen, DNS-Eintrag, lokalen hosts-Eintrag, nicht standardmäßigen Port, Tunnelalias oder HostKeyAlias. Gehashte known-host-Namen erschweren die manuelle Kontrolle, obwohl ssh-keygen -F sie suchen kann. Ein Platzhaltermuster vergrößert die Übereinstimmung, widerruft den Schlüssel jedoch nur für Ziele innerhalb dieses Musters und erschwert die Prüfung des beabsichtigten Umfangs.

Der KRL-Fall muss denselben Server, Benutzerschlüssel, Netzwerkweg und dieselben vertrauenswürdigen known-host-Einträge verwenden. Ändern Sie nur den Widerrufsmechanismus. Mit aktivem RevokedHostKeys müssen sowohl revoked-lab als auch 127.0.0.1 nach Vorlage des Vorrichtungsschlüssels scheitern. Das gepaarte Experiment macht aus einer abstrakten Aliaswarnung einen sichtbaren, wiederholbaren Fehler.

Testen Sie auch die Priorität. OpenSSH behält für eine Option den zuerst ermittelten Wert, weshalb eine frühe hostspezifische Einstellung den später beabsichtigten Standard aushebeln kann. Führen Sie ssh -G für jedes Ziel aus und vergleichen Sie den aufgelösten Pfad revokedhostkeys bytegenau. Das bloße Wort RevokedHostKeys irgendwo in einer Konfigurationsdatei beweist nicht, dass der Agent die Datei verwendet.

System- und Benutzerkonfiguration erzeugen eine weitere Trennung. Bei einem Entwickler kann /etc/ssh/ssh_config auf die KRL der Organisation verweisen, während der Agent mit ssh -F private-config startet und OpenSSH eine andere Datei lesen lässt. Umgekehrt kann ein sauberes CI-Konto den Test bestehen, ohne einen Produktionsrunner mit Optionen in der Befehlszeile abzubilden. Erfassen Sie den vollständigen Aufruf an der Aktionsgrenze des Agenten und machen Sie den Widerrufspfad dort ausdrücklich.

Berechtigungen gehören zur Abnahme. Laut OpenSSH-Handbuch verweigert ein Lesefehler bei RevokedHostKeys die Authentifizierung aller Hosts. Prüfen Sie die Datei vor der Verbindung als Betriebssystembenutzer des Agenten und fragen Sie den vorgesehenen Schlüssel ab. So trennen Sie drei Ergebnisse, die alle wie ein fehlgeschlagener SSH-Befehl aussehen: gültiger Widerrufstreffer, fehlende oder unlesbare Datei und fehlerhafte KRL.

Auch die Verteilung hat eine Zeitkante. Können mehrere Runner den Agenten starten, ist die Veröffentlichung auf nur einem Rechner kein vollständiger Widerruf. Erfassen Sie einen Inhaltsdigest der KRL und verlangen Sie ihn von jedem Runner, bevor neue SSH-Arbeit zugelassen wird. Ersetzen Sie die Datei atomar, damit kein Leser eine teilweise geschriebene Fassung sieht. Führen Sie den Negativtest nach der Verteilung auf jeder unterschiedlichen Clientabbildung oder Konfigurationsklasse aus, nicht nur auf dem KRL-Erzeuger.

Ein Rollback braucht eine prüfbare Bedeutung. Das Entfernen eines Fingerabdrucks nach dem Schließen eines Tickets kann Vertrauen wiederherstellen, obwohl der kompromittierte private Schlüssel weiter existiert. Ersetzen Sie besser die Serveridentität, verteilen Sie den neuen Vertrauenseintrag und halten Sie die alte Identität widerrufen. Falls die Richtlinie ein späteres Entfernen erlaubt, verlangen Sie den Nachweis, dass der alte private Schlüssel nicht zurückkehren kann, und behalten Sie einen Regressionstest, der ihn vorlegt.

Der Abnahmenachweis einer widerrufenen Identität sollte daher Fingerabdruck, Algorithmus, KRL-Digest, getestete Zielformen, effektive Konfiguration jeder Form und Ergebnis eines neuen Austauschs enthalten. Erfassen Sie das Ergebnis der Multiplexsitzung getrennt, weil es eine andere Frage beantwortet. Prüfer können so Identitätsabgleich, Pfadabdeckung, Konfiguration, Verteilung und Transportbereinigung unterscheiden.

Eine neue Verbindung muss vor dem Marker scheitern

Zwingen Sie den ersten Negativfall zu einem neuen Transport. Deaktivieren Sie die gemeinsame Verbindung in der Befehlszeile, auch wenn die Benutzerkonfiguration sie aktiviert, halten Sie den Client nicht interaktiv und setzen Sie einen unverwechselbaren Marker in den entfernten Befehl.

work="$PWD/ssh-revocation-fixture"
config="$work/client/config"
log="$work/client/direct.stderr"

set +e
ssh -F "$config" \
  -o ControlMaster=no -o ControlPath=none \
  -i "$work/client/id_ed25519" \
  -p 2222 [email protected] \
  'printf REVOKED_KEY_EXECUTED' \
  >"$work/client/direct.stdout" 2>"$log"
rc=$?
set -e

if [ "$rc" -eq 0 ]; then
  printf '%s\n' 'FAIL: SSH accepted a revoked host identity'
  exit 1
fi
if grep -q REVOKED_KEY_EXECUTED "$work/client/direct.stdout"; then
  printf '%s\n' 'FAIL: remote sentinel ran'
  exit 1
fi
printf 'PASS rc=%s\n' "$rc"

Prüfen Sie das Ergebnis, nicht einen exakten englischen Fehlertext. OpenSSH-Versionen und Betriebssysteme können Meldungen anders formulieren. Bewahren Sie bei einem Fehler die ausführliche Ausgabe eines zweiten Laufs mit -vv auf und suchen Sie nach dem vorgelegten Fingerabdruck sowie der Widerrufsmeldung. TCP-Zeitüberschreitung, abgelehnter Port, unbekannter Host, fehlender Benutzerschlüssel oder gesperrtes Konto liefern ebenfalls einen Wert ungleich null, beweisen aber keinen Widerruf.

Das Serverprotokoll liefert die zweite Hälfte. Der Client muss während des Schlüsselaustauschs abbrechen, bevor der Server eine erfolgreiche Benutzerauthentifizierung erfasst und eine Sitzung startet. Kann die Vorrichtung diese Phasen nicht unterscheiden, ist sie für den Test zu undurchsichtig.

Führen Sie einen Kontrollfall mit einer leeren lesbaren KRL oder einem anderen nicht widerrufenen Serverschlüssel aus. Diese Verbindung muss BASELINE_OK erreichen. Ein Negativtest ohne Positivkontrolle besteht häufig nur, weil DNS, Routing, Berechtigungen oder das Konto bereits defekt waren.

Jede Alias- und Adressform braucht einen eigenen Fall

Eine KRL sollte den Schlüssel unter allen Namen ablehnen, doch die Konfigurationsauflösung kann eine Schreibweise noch an der Widerrufsoption vorbeiführen. Testen Sie die effektive Clientkonfiguration und das Netzwerkergebnis jeder Zielform, die der Agent erzeugen kann.

Beginnen Sie mit einer kleinen Matrix für die Vorrichtung:

1. Der konfigurierte Alias wie revoked-lab, dessen HostName auf die Testadresse zeigt.
2. Der vollständig qualifizierte Hostname und jeder von lokalen Regeln akzeptierte Kurzname.
3. Die IPv4-Adresse und, falls der Listener sie besitzt, die IPv6-Adresse.
4. Der known-host-Bezeichner für einen nicht standardmäßigen Port, üblicherweise als [host]:port geschrieben.
5. Ein Alias mit HostKeyAlias, weil diese Option den echten Namen bei Schlüsselsuche und Zertifikatsprüfung ersetzt.

Speichern Sie die Varianten in einer Datendatei oder Testfunktion, statt Shellblöcke zu duplizieren. Untersuchen Sie für jeden sichtbaren Namen ssh -G destination und speichern Sie hostname, port, hostkeyalias, userknownhostsfile, revokedhostkeys, proxycommand, proxyjump, controlmaster und controlpath. ssh -G erweitert die Konfiguration ohne Verbindung und entdeckt damit einen Host-Abschnitt, der den KRL-Pfad still ersetzt.

Hostname und HostKeyAlias haben verschiedene Aufgaben. Hostname wählt das Netzwerkziel. HostKeyAlias wählt den Namen, unter dem OpenSSH Schlüssel liest oder speichert und Zertifikate prüft. Keine Option sollte eine globale RevokedHostKeys-Prüfung schwächen, beide können aber den berücksichtigten known-host-Eintrag ändern. Eine nur an den Hostnamen gebundene @revoked-Zeile ist deshalb eine schlechte Vorfallskontrolle.

Die Kanonisierung braucht einen Fall, wenn sie aktiv ist. CanonicalizeHostname yes kann konfigurierte Domänen anhängen und lässt OpenSSH die Konfiguration mit dem umgeschriebenen Ziel erneut verarbeiten. Ein später passender Abschnitt kann eine andere known-hosts-Datei wählen oder die Widerrufsdatei auslassen. Testen Sie die kurze Eingabe und den resultierenden kanonischen Namen und bestätigen Sie in beiden effektiven Konfigurationen dieselbe KRL.

Betrachten Sie CheckHostIP=yes nicht als Aliasabdeckung. Das OpenSSH-Handbuch sagt, dass es zusätzlich die Ziel-IP in known-hosts prüft und bei einem ProxyCommand nicht verfügbar ist. Es erkennt eine geänderte Zuordnung, ersetzt aber keine schlüsselbezogene Widerrufsdatei. Proxy- und Sprungpfade brauchen weiterhin einen vollständigen Test des Endziels sowie eigenes Vertrauen für jeden Sprunghost.

Zwischengespeicherte Verbindungen begrenzen die Vorfallsreaktion

Eine aktive multiplexierte SSH-Masterverbindung hat den Server bereits authentifiziert. Eine weitere Sitzung über ihren Kontroll-Socket erzeugt keine neue TCP-Verbindung und keinen neuen Hostschlüsselaustausch, weshalb eine frisch installierte KRL den Schlüssel nicht rückwirkend ablehnen kann. Das als Umgehung zu bezeichnen, verwischt das Modell. Ein noch bestehender authentifizierter Transport wird wiederverwendet.

Beweisen Sie dieses Verhalten in der Vorrichtung, statt auf einen Neustart zu vertrauen. Stellen Sie zuerst einen Master her, solange der Schlüssel erlaubt ist. Halten Sie ihn mit ControlPersist offen, fügen Sie den Schlüssel zur KRL hinzu und zeigen Sie, dass ssh -O check den Master noch findet. Ein Befehl über den Socket kann weiterhin laufen. Erfassen Sie das als erwartete Kontrolle vor der Behebung, nicht als bestandenen Widerruf.

Führen Sie dann die Reaktion aus: Hindern Sie den Agenten an neuer Arbeit, beenden Sie die betroffenen Master und widerrufen oder stoppen Sie die besitzende Agentensitzung. Für einen eigenen Socket der Vorrichtung sieht der lokale Befehl so aus:

socket="$PWD/ssh-revocation-fixture/client/cm-testuser-127.0.0.1-2222"
ssh -S "$socket" -O exit [email protected]

Wiederholen Sie nach dem Verschwinden des Sockets die Verbindung mit ControlMaster=no und ControlPath=none; sie muss am widerrufenen Schlüssel scheitern. Testen Sie nach der Bereinigung auch die übliche Multiplexkonfiguration des Agenten. Opportunistische Modi wie ControlMaster auto weichen ohne aktiven Master auf eine neue Verbindung aus, die die KRL treffen muss.

Eine veraltete Socketdatei ist keine authentifizierte Verbindung. OpenSSH versucht sie, erkennt den fehlenden Master und kann auf eine normale Verbindung zurückfallen. Behalten Sie den Fall, weil Abstürze alte Dateien hinterlassen. Das sichere Ergebnis bleibt ein Widerrufsfehler im neuen Austausch.

Der Widerruf während eines aktiven Vorfalls braucht daher zwei Kontrollen: zukünftige Schlüsselaustausche ablehnen und vor dem Widerruf authentifizierte Transporte beenden. Ein Test nur einer Kontrolle lässt dem Agenten einen neuen oder einen nie geschlossenen alten Weg.

Ein Server kann mehrere Identitäten vorlegen

Server laden oft mehrere Hostschlüssel oder ein Hostzertifikat samt zugrunde liegendem Schlüssel. Der Widerruf eines Fingerabdrucks macht den Endpunkt nicht zwingend unerreichbar. Bei der Aushandlung wählen Client und Server einen gemeinsamen Algorithmus; ein anderer vertrauenswürdiger und nicht widerrufener Schlüssel kann denselben Server authentifizieren.

Entscheiden Sie, was die Vorfallsaussage bedeutet. Ist ein privater Hostschlüssel abgeflossen, muss der Client diesen ablehnen, während ein unabhängig geschützter Schlüssel nach Prüfung gültig bleiben kann. Hat die Maschine ihre Integrität verloren, widerrufen Sie alle vorlegbaren Identitäten einschließlich Zertifikaten und entfernen Sie Vertrauen bis zum Neuaufbau. «Host widerrufen» ohne Identitätsliste überlässt die Entscheidung der Aushandlung.

Inventarisieren Sie anhand der Daemonkonfiguration und Vertrauenseinträge, nicht mit einem einzigen Scan. Testen Sie jeden aktiven Algorithmus, indem Sie HostKeyAlgorithms darauf begrenzen. Der widerrufene Schlüssel muss scheitern. Jede erlaubte Identität braucht einen eigenen Positivfall und dokumentierten Fingerabdruck.

Hostzertifikate bringen eine weitere Unterscheidung. Sie können das Zertifikat als öffentliches Objekt, seine Seriennummer oder ID in einer KRL oder die CA für eine ganze Hostklasse widerrufen. Diese Varianten haben verschiedene Reichweiten. Das ssh-keygen-Handbuch dokumentiert KRL-Anweisungen für Seriennummern, IDs, öffentliche Schlüssel und Fingerabdrücke; fragen Sie die fertige KRL mit der tatsächlich vorgelegten Zertifikatsdatei ab.

Auch UpdateHostKeys verdient Aufmerksamkeit. OpenSSH kann nach der Authentifizierung mit einem bereits vertrauenswürdigen einfachen Schlüssel weitere Serverschlüssel lernen. Das unterstützt geplante Rotation, doch früher gelernte Alternativen bleiben Kandidaten, sofern der Widerruf sie nicht umfasst. Geben Sie die known-hosts-Einträge mit ssh-keygen -F für jeden Namen und jede Form [name]:port aus und vergleichen Sie jeden öffentlichen Schlüssel mit dem Vorfallsumfang.

Führen Sie den Negativtest über den echten Agentenweg aus

Ein Terminaltest unter dem Konto eines Entwicklers beweist nicht, dass ein autonomer Agent dasselbe SSH-Programm, dieselbe Konfiguration, dasselbe Homeverzeichnis, denselben Resolver, Proxy oder Socket verwendet. Die endgültige Suite muss die genaue Aktionsgrenze des Agenten mit seiner Produktionsumgebung aufrufen.

Lassen Sie für jede Variante strukturierte Nachweise zurückgeben: Ziellabel, aufgelösten Namen und Port, vorgelegten Fingerabdruck, KRL-Digest, Status der Verbindungsteilung, Exitcode, Auftreten des Markers und Abbruchphase des Servers. Nehmen Sie keine Geheimnisse auf. Die nützliche Aussage ist einfach: Die widerrufene Identität erschien, der Client erkannte sie und danach folgten weder Benutzerauthentifizierung noch Befehl.

Eine isolierte Umgebung deckt versehentliche Abhängigkeiten auf. Setzen Sie ausdrücklich SSH-Konfigurationspfad, known-hosts-Datei, KRL, Identitätsdatei und Kontrollpfad. Leeren oder ersetzen Sie SSH_AUTH_SOCK, wenn der Agent keine fremden Schlüssel nutzen darf. Begrenzen Sie die Verbindungszeit, damit CI nicht hängt. Bewahren Sie stderr und Serverlogs bei Fehlern auf; ein Erfolgsbericht kann Hashes und entscheidende Zeilen enthalten.

Wenn Agenten SSH über Sallyport ausführen, nutzen Sie diesen Weg im Negativtest: Der gebündelte zustandslose Helfer sp-ssh führt SSH-Aktionen aus, während Sessions und Activity den Agentenlauf und den einzelnen Aufruf erfassen. Prüfen Sie die Kette bei Bedarf offline mit sp audit verify; die Schlüsselablehnung muss weiterhin aus der SSH-Vertrauenskonfiguration des echten Aktionswegs stammen.

Schwächen Sie den Client nicht für bequemere Automatisierung. StrictHostKeyChecking=no, ein leeres known-hosts-Ziel oder Diagnose nach /dev/null machen aus dem Sicherheitstest eine Erreichbarkeitsprüfung. BatchMode=yes entfernt Rückfragen, ersetzt aber kein fehlendes Vertrauensmaterial.

Der Widerrufstest sollte nur aus einem Grund scheitern

Nehmen Sie die Matrix in CI auf, aber halten Sie die Vorrichtung klein genug für Diagnosen. Führen Sie eine Positivkontrolle mit erlaubter Identität aus, prüfen Sie die KRL vorab, starten Sie den Listener und testen Sie neue Verbindungen. Behandeln Sie Multiplexing in einer getrennten Phase, weil Einrichtung und Erwartung abweichen. Stoppen Sie am Ende den Listener und prüfen Sie, dass kein Master oder Socket bleibt.

Verwerfen Sie den Build, wenn ein Ziel den Marker erreicht, einer effektiven Konfiguration die Widerrufsdatei fehlt oder der Server eine nicht klassifizierte Identität anbietet. Verwerfen Sie auch unklare Läufe. Zeitüberschreitung oder unlesbare KRL bedeuten einen defekten Test, obwohl SSH einen Fehlercode liefert.

Bewahren Sie erwarteten Fingerabdruck und KRL-Digest im Bericht auf. Ändert eine Rotation die Vorrichtungsidentität, muss die Prüfung beide Werte gemeinsam geändert zeigen. Diese kleine Hürde verhindert, dass der Server einen neuen Schlüssel erhält, während der Test weiter eine aufgegebene öffentliche Datei widerruft.

Starten Sie die Suite mit einem Agentenprozess ohne Rückfragemöglichkeit. Freigabedialog, Passwortfrage oder Hostbestätigung können bis zu einer allgemeinen Zeitüberschreitung warten und die Ursache verdecken. BatchMode=yes sollte diese Wege sofort scheitern lassen, während die Positivkontrolle bestätigt, dass keine Interaktion nötig ist. Setzen Sie außen eine harte Zeitgrenze, zählen Sie sie aber nie als Widerrufsnachweis.

Bewahren Sie für jede unterstützte Clientversion eine bereinigte ausführliche Ablaufspur auf. Sie zeigt die Reihenfolge von Konfigurationserweiterung, Wiederverwendung, Schlüsselaustausch, Auswahl und Ablehnung. Wenn ein Update Verhalten oder Text von OpenSSH ändert, vergleichen Sie die neue Spur und passen Prüfungen erst nach Bestätigung von Fingerabdruck und Phase an. Sicherheitstests verfallen, wenn jedes neue Scheitern als harmlose Ausgabeänderung gilt.

Bewahren Sie das unbequeme Ergebnis mit aktivem Master. Es erinnert daran, dass die Verteilung einer KRL keine Sitzung widerruft. Schließen Sie bestehende Transporte, beweisen Sie den Schlüsselaustausch beim nächsten Versuch und beobachten Sie die Ablehnung des exakt markierten Fingerabdrucks. Erst dann ist gezeigt, dass Aliase, Cache und Adressschreibweise dem Agenten den Zugang nicht zurückgeben.