SSH-Zertifikate für KI-Agenten und lokale Verwahrung von Zugangsdaten

SSH-Zertifikate und die lokale Verwahrung von Zugangsdaten ergänzen sich. Ein Zertifikat gibt einem SSH-Server eine zeitlich begrenzte Aussage über einen öffentlichen Schlüssel. Die lokale Verwahrung hält den zugehörigen privaten Zugang aus dem Kontext, den Dateien, Unterprozessen und Protokollen eines KI-Agenten heraus. Wer eines von beiden als Ersatz für das andere behandelt, lässt eine Lücke offen, die im ungünstigsten Moment sichtbar wird.

Die verbreitete Darstellung dieses Konzepts lautet, dass ein 15-Minuten-Zertifikat alles sicher macht. Das stimmt nicht. Wenn der Agent den privaten Schlüssel lesen kann, kann er ihn bis zum Ablauf des Zertifikats weiterverwenden, ein weiteres Zertifikat anfordern, sofern er die Ausstellung erreichen kann, oder eine Kopie in einem Arbeitsverzeichnis hinterlassen, das den Lauf überdauert. Eine kurze Gültigkeit verkürzt die Zeit, in der der Server den Zugang akzeptiert. Sie entfernt die Fähigkeit aber nicht aus dem Prozess, der das Geheimnis besitzt.

Für Agenten, die Infrastruktur ändern können, sollten Sie Zertifikate verwenden, um die akzeptierte Lebensdauer zu verkürzen, und lokale Verwahrung, um die Offenlegung des privaten Zugangs zu verhindern. Entwerfen Sie Erneuerung, Unterbrechung und Widerruf anschließend als ein gemeinsames Betriebssystem. Die Details sind wichtiger als die Zertifikatslaufzeit, die auf einem Diagramm steht.

Ein Zertifikat begrenzt die Akzeptanz, nicht den Besitz

Ein OpenSSH-Benutzerzertifikat ist ein signierter öffentlicher Schlüssel mit Einschränkungen. Der SSH-Server prüft die CA-Signatur und Felder wie Zertifikatstyp, Gültigkeitszeitraum, Principal-Liste, kritische Optionen und Erweiterungen. Der Client muss weiterhin beweisen, dass er den privaten Schlüssel kontrolliert, der zum zertifizierten öffentlichen Schlüssel gehört.

Diese Unterscheidung wird ständig verwischt. Ein Zertifikat besteht aus öffentlichen Daten. Sie können id_ed25519-cert.pub neben einen privaten Schlüssel legen, auf einen Client kopieren und frei untersuchen. Das Geheimnis bleibt id_ed25519. Wenn ein Agent diese private Datei erhält, begrenzt die kurze Zertifikatslaufzeit nur, wie lange ein ausgestelltes Zertifikat funktioniert. Der Agent besitzt weiterhin einen wiederverwendbaren Signaturschlüssel.

OpenSSH beschreibt das Zertifikatsformat in PROTOCOL.certkeys und stellt die üblichen Optionen zur Erstellung im Handbuch von ssh-keygen bereit. Der Signierbefehl übernimmt mit -s einen privaten CA-Schlüssel, mit -I eine Identitätszeichenfolge, mit -n erlaubte Principals und mit -V eine Gültigkeitsangabe. Das sind Autorisierungsvorgaben und keine dekorativen Metadaten. Ein Server muss so konfiguriert sein, dass er der CA vertraut und die Principals auswertet, bevor sie den Zugriff beeinflussen.

Betrachten Sie zwei Entwürfe:

• Im ersten erhält ein Agent id_ed25519, ein Zertifikat und den CA-Endpunkt. Der Agent kann SSH-Herausforderungen selbst signieren und möglicherweise weitere Zertifikatsanfragen stellen.
• Im zweiten verwahrt ein lokaler Executor id_ed25519 in einem geschützten Speicher. Der Agent fordert eine benannte SSH-Aktion an, und der Executor übernimmt die SSH-Authentifizierung, ohne private Daten zurückzugeben.

Beide Entwürfe können dasselbe Zertifikat verwenden. Nur der zweite verhindert, dass eine Prompt-Injection im Agenten, ein kompromittiertes Plugin oder ein neugieriger Unterprozess den privaten Zugang kopiert.

Verwenden Sie auch das Identitätsfeld eines Zertifikats nicht als Beweis für die Verwahrung. Der Wert von -I hilft Menschen, Ausstellungs- und Zugriffsprotokolle miteinander zu verknüpfen. Jeder Aufrufer, der Zertifikate anfordern kann, darf jedoch eine eindrucksvoll klingende Identität wählen. Binden Sie die Ausstellung an einen bekannten öffentlichen Schlüssel und eine bekannte Agentensitzung. Wenn Ihre Ausstellungsstelle beliebige öffentliche Schlüssel und beliebige Identitätszeichenfolgen akzeptiert, wird Ihre Prüfspur unter Druck zur Fiktion.

Lokale Verwahrung verändert den Fehler, auf den Sie sich vorbereiten müssen

Wenn ein Zugang lokal bleibt, wird aus einem Vorfall mit Geheimnisabfluss ein Vorfall zur Autorisierung einer Aktion. Das ist das bessere Problem, aber weiterhin ein Problem. Der Agent kann einen destruktiven Befehl anfordern, den falschen Host ansprechen oder eine genehmigte Sitzung länger nutzen, als der Betreiber beabsichtigt hat.

Die lokale Komponente sollte den privaten SSH-Zugang halten und die Protokolloperation selbst ausführen. Der Agent sollte die Befehlsausgabe, den Exit-Status und begrenzte Diagnoseinformationen erhalten. Er sollte weder den privaten Schlüssel als Text noch einen temporären Dateipfad, eine Umgebungsvariable, einen weiterleitbaren SSH-Agent-Socket oder einen scheinbar redigierten Wert erhalten, den ein anderes Tool auflösen kann.

Ein häufiger schlechter Kompromiss besteht darin, ein Geheimnisverzeichnis schreibgeschützt in die Agentenumgebung einzubinden. Schreibschutz schützt vor Änderungen, nicht vor dem Lesen. Ein weiterer schlechter Kompromiss legt den privaten Schlüssel in einen SSH-Agenten und gibt jedem Kindprozess Zugriff auf SSH_AUTH_SOCK. Das kann für eine streng kontrollierte interaktive Shell akzeptabel sein. Ein autonomer Coding-Agent startet jedoch Tools, Test-Runner, Package-Hooks und Hilfsprozesse. Jeder davon vergrößert den Kreis der Prozesse, die den Agenten zum Signieren auffordern können.

Die lokale Verwahrung schafft außerdem einen sinnvollen Punkt für menschliche Kontrolle. Eine Person kann die erste Aktion eines neuen Prozesses genehmigen, bei sensiblen Zugangsdaten jedes Mal eine Genehmigung verlangen oder den Tresor vollständig sperren. Diese Kontrollen ersetzen keine Autorisierung auf dem Server. Sie entscheiden, ob ein Prozess überhaupt versuchen darf, eine Aktion auszuführen.

Halten Sie diese Grenze eng. Die Komponente, die den privaten Schlüssel verwahrt, sollte keinen beliebigen Shell-Text akzeptieren und ihn blind ausführen, nur weil der Agent ihn geliefert hat. Sie sollte Host, Zielkonto und angeforderte Aktion kennen und diese Angaben vor oder zusammen mit der Ausführung protokollieren. Wenn Sie nicht nachvollziehen können, welcher Prozess ssh deploy@host angefordert hat, ist die lokale Verwahrung zu einem Geheimniswrapper mit schlechter Nachvollziehbarkeit geworden.

Die praktische Konsequenz ist klar: Die Zertifikatserneuerung sollte die öffentliche Autorisierung aktualisieren, während die lokale Verwahrung weiterhin die private Signatur kontrolliert. Erstellen Sie den privaten Zugang nicht bei jedem Zertifikatsablauf neu, sofern es keinen gesonderten Grund für eine Rotation gibt.

Die Zertifikatslaufzeit sollte sich an der Unterbrechungstoleranz orientieren

Wählen Sie die Gültigkeit danach, wie lange Sie einen bereits ausgestellten Zugang nach dem Stoppen neuer Arbeit tolerieren können. Die richtige Antwort ist bei einem schreibgeschützten Diagnose-Lauf, einem Deployment-Workflow und einem Agenten, der Zugriffskontrollen ändern kann, jeweils anders.

Beginnen Sie mit einer Dauer, die Raum für echte Arbeit lässt. Die Erneuerung von Zertifikaten scheitert häufiger als erwartet, weil Laptops in den Ruhezustand wechseln, sich VPN-Routen ändern, die CA kurzzeitig nicht erreichbar ist, ein langer Befehl eine Verbindung offen hält oder die Systemuhr abweicht. Eine sehr kurze Laufzeit macht gewöhnliche Unterbrechungen zu einer ständigen Quelle für Wiederholungslogik und verlockende Umgehungen.

Für viele autonome Aufgaben sind 15 bis 60 Minuten ein vernünftiger Ausgangspunkt. Verwenden Sie das untere Ende, wenn das Konto Produktionssysteme beeinflussen kann. Wählen Sie ein längeres Fenster nur, wenn die Aufgabe es wirklich benötigt und Sie den Grund benennen können. Ein mehrstündiges Zertifikat für eine Aufgabe, die zehn Minuten läuft, ist meist Bequemlichkeit, die als betriebliche Notwendigkeit getarnt wird.

Verwechseln Sie die Zertifikatsgültigkeit nicht mit der Lebensdauer einer SSH-Verbindung. SSH authentifiziert bei der Einrichtung einer Verbindung. Ein Server beendet eine bereits authentifizierte Sitzung normalerweise nicht, wenn das Zertifikat abläuft. Verbindungs-Multiplexing kann das noch überraschender machen: Ein späterer Befehl verwendet möglicherweise eine bestehende authentifizierte Master-Verbindung, statt das Zertifikat erneut zu prüfen.

Dieses Verhalten verändert den Entwurf:

1. Legen Sie die Zertifikatsgültigkeit so fest, dass sie neue Authentifizierungen begrenzt.
2. Begrenzen Sie die Dauer von Befehlen oder Sitzungen zusätzlich im lokalen Executor.
3. Übergeben Sie einem Agenten keinen wiederverwendbaren Multiplexing-Control-Socket.
4. Beenden Sie aktive Sitzungen im Notfall, wenn die Aktion selbst gestoppt werden muss.

Die OpenSSH-Option ControlMaster in ssh_config ist für interaktive Geschwindigkeit nützlich, untergräbt aber einfache Annahmen über die Authentifizierung jedes einzelnen Befehls. Deaktivieren Sie Multiplexing für sensible Ziele bei autonomer Arbeit oder lassen Sie den Executor die Verbindung verwalten und beenden. Lassen Sie einen Agenten keinen Control-Pfad erben, der noch authentifiziert bleibt, obwohl seine Genehmigung oder sein Zertifikatsfenster bereits abgelaufen sein sollte.

Auch die Uhrzeitsynchronisation gehört in diesen Abschnitt. Ein Zertifikat hat ein absolutes Gültigkeitsintervall. Wenn Ausstellungsrechner und Zielserver deutlich unterschiedliche Uhrzeiten haben, kann ein frisch erstelltes Zertifikat abgelaufen oder noch nicht gültig wirken. Überwachen Sie die Zeitsynchronisation auf beiden Seiten und brechen Sie ab, wenn der Server das Gültigkeitsfenster ablehnt. Umgehen Sie einen Uhrfehler nicht durch ein deutlich längeres Zertifikat.

Die Erneuerung muss beweisen, dass dieselbe Verwahrungsgrenze noch besteht

Ein Erneuerungsdienst sollte ein neues Zertifikat erst ausstellen, wenn er die Anfrage mit dem lokal verwahrten Zugang, der aktuellen Agentensitzung und dem angeforderten Autorisierungsumfang verknüpfen kann. Die bloße Annahme eines öffentlichen Schlüssels in einer HTTP-Anfrage beweist nichts darüber, wer die zugehörige private Hälfte kontrolliert.

Der sauberste Ablauf lässt den lokalen Executor bei der Erneuerung den Besitz seines registrierten öffentlichen Schlüssels nachweisen. Die Ausstellungsstelle prüft diesen Nachweis, kontrolliert die aktive Sitzung und den angeforderten Principal, signiert den öffentlichen Schlüssel und gibt nur das öffentliche Zertifikat zurück. Der Executor verbindet dieses Zertifikat für die nächste SSH-Verbindung mit dem intern verwahrten privaten Zugang.

Ein Befehl zur Zertifikatserstellung auf der Ausstellungsstelle könnte so aussehen:

ssh-keygen -s agent_user_ca -I run-4821 -n deploy-prod -V +30m agent-run-4821.pub

Dieser Befehl signiert agent-run-4821.pub mit dem privaten CA-Schlüssel. Er erstellt ein zugehöriges öffentliches Zertifikat, das normalerweise agent-run-4821-cert.pub heißt. Die Zeichenfolge run-4821 hilft beim Verknüpfen von Protokollen, deploy-prod ist der erlaubte Principal und +30m fordert ein Intervall von dreißig Minuten an. Die Ausstellungsstelle sollte diese Identitätszeichenfolge selbst erzeugen und nicht einer vom Agenten gelieferten Bezeichnung vertrauen.

Prüfen Sie jedes neue Zertifikat, bevor Sie die Automatisierung davon abhängig machen:

ssh-keygen -L -f agent-run-4821-cert.pub

Die Ausgabe enthält Zertifikatstyp, Fingerabdruck der signierenden CA, Identität, Seriennummer, Gültigkeitszeitraum, Principals, kritische Optionen und Erweiterungen. Machen Sie diese Prüfung zu einem Bestandteil der Tests für Ihre Ausstellungsstelle. Ein fehlender Principal, ein erst in der Zukunft beginnender Gültigkeitszeitraum oder eine unerwartete Erweiterung würde sonst als fehlgeschlagenes Deployment sichtbar, worauf jemand nach einem langlebigen Ersatzschlüssel greifen könnte.

Erneuern Sie das Zertifikat, bevor die Arbeit eine neue SSH-Verbindung benötigt, nicht genau in der Sekunde des Ablaufs. Der Executor kann gegen Ende des Intervalls einen Ersatz anfordern, während das bestehende Zertifikat noch funktioniert. Er sollte außerdem den Start eines Befehls verweigern, wenn für dessen erlaubte Dauer zu wenig Zertifikatslaufzeit verbleibt. Diese Prüfung verhindert, dass ein Job unmittelbar vor dem Scheitern der nächsten Authentifizierung mit einem wichtigen Schreibvorgang beginnt.

Gestalten Sie die Erneuerung auf Anfrageebene idempotent. Eine verlorene Antwort kann dazu führen, dass ein Client erneut anfragt, obwohl die Ausstellungsstelle bereits ein gültiges Zertifikat erstellt hat. Speichern Sie Anfragekennung, Sitzungskennung, Fingerabdruck des öffentlichen Schlüssels, Principal und Ablaufzeit. Geben Sie bei einer Wiederholung das bereits ausgestellte Zertifikat zurück, wenn die Eingaben übereinstimmen. Weichen sie ab, lehnen Sie die Anfrage ab, statt zu erraten, welche Anfrage der Agent gemeint hat.

Principals und Serverrichtlinien bestimmen, was das Zertifikat darf

Ein Zertifikat sagt, wer sich authentifizieren darf. Der Server entscheidet weiterhin, welches lokale Konto diese Identität akzeptiert und was dieses Konto tun kann. Wenn Sie einem Agentenzertifikat die Authentifizierung als weitreichendes gemeinsames Administratorkonto erlauben, hilft auch eine kurze Laufzeit nicht gegen eine zu großzügige Autorisierungsentscheidung.

OpenSSH kann über TrustedUserCAKeys einer Benutzer-CA vertrauen. Akzeptierte Principals lassen sich dann mit AuthorizedPrincipalsFile oder AuthorizedPrincipalsCommand zuordnen. Die zweite Option ist nützlich, wenn ein Server eine zentral verwaltete Kontozuordnung braucht, bringt aber eine zusätzliche Verfügbarkeitsabhängigkeit beim Login mit sich. Eine statische Principals-Datei ist weniger flexibel und bei einer kleinen Flotte oft leichter zu verstehen.

Eine eingeschränkte Serverkonfiguration kann so aussehen:

TrustedUserCAKeys /etc/ssh/agent_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedHostKeys /etc/ssh/revoked_agent_credentials.krl

Für ein lokales Konto namens deploy könnte /etc/ssh/auth_principals/deploy nur Folgendes enthalten:

deploy-prod

Damit akzeptiert der Server ein Zertifikat der benannten CA nur dann, wenn es deploy-prod als Principal enthält und nicht durch die konfigurierte KRL widerrufen wurde. Testen Sie die genaue OpenSSH-Version auf Ihren Servern. Konfigurationsdirektiven und Zertifikatsverhalten sind grundsätzlich stabil, doch Paketierung und ältere Versionen können beeinflussen, worauf Sie sich verlassen können.

Kritische Optionen und Erweiterungen von Zertifikaten können die Nutzung weiter einschränken. OpenSSH unterstützt kritische Optionen wie force-command und source-address sowie Erweiterungen wie permit-pty, permit-port-forwarding und permit-agent-forwarding. Verwenden Sie diese, wenn der Ziel-Workflow eine klar begrenzte Form hat. Ein Agent, der nur einen Deployment-Helfer ausführt, sollte nicht versehentlich eine allgemeine interaktive Shell erhalten.

Versehen Sie ein Agentenzertifikat nicht mit einer allgemeinen permit-pty-Fähigkeit, nur weil später jemand eine Diagnose benötigen könnte. Stellen Sie bei Bedarf einen separaten, bewusst genehmigten Diagnosezugang aus. Bequemlichkeitserweiterungen bleiben häufig lange bestehen, nachdem die Ausnahmeaufgabe, die sie rechtfertigte, beendet ist.

Ein Notfallwiderruf erfordert mehr als das Warten auf den Ablauf

Eine kurze Laufzeit hilft bei der routinemäßigen Eindämmung. Wenn Sie die Ausstellung stoppen und das Zertifikat in dreißig Minuten abläuft, enden neue SSH-Authentifizierungen nach diesem Zeitraum. Das kann ausreichen, wenn Sie eine fehlerhafte Aufgabe erkannt haben, bevor sie ein sensibles Ziel erreicht hat. Es reicht nicht aus, wenn ein privater Zugang möglicherweise nach außen gelangt ist oder ein Agent schädliche Arbeit begonnen hat.

Stoppen Sie als erste Maßnahme die Ausstellung neuer Zertifikate für die betreffende Sitzung, den Zugang oder die CA. Verhindern Sie anschließend bereits ausgestellten Zugängen die Authentifizierung auf den Servern, wenn die Dringlichkeit das erfordert. In OpenSSH bietet eine Key Revocation List, kurz KRL, Servern die Möglichkeit, bestimmte Zertifikate, öffentliche Schlüssel oder eine signierende CA abzulehnen.

Um ein ausgestelltes Zertifikat in eine KRL aufzunehmen, kann ein Betreiber einen Befehl wie diesen verwenden:

ssh-keygen -k -f revoked_agent_credentials.krl -s agent_user_ca.pub agent-run-4821-cert.pub

Das Argument -s bezeichnet die CA, die das Zertifikat signiert hat. Verteilen Sie die resultierende KRL an die Zielserver, verwenden Sie den mit RevokedHostKeys konfigurierten Pfad einheitlich und laden Sie sshd gemäß Ihrem Betriebsverfahren neu. Testen Sie den vollständigen Ablauf im Voraus: Erstellen Sie ein Zertifikat, authentifizieren Sie sich erfolgreich, nehmen Sie es in die KRL auf, verteilen Sie die Datei, laden Sie sshd neu und prüfen Sie, dass eine neue Authentifizierung fehlschlägt.

Eine KRL ist kein zentraler Notausschalter. Jeder SSH-Server muss die Datei erhalten und einlesen. Wenn ein Host nicht erreichbar oder offline ist oder unter einer getrennten Konfiguration verwaltet wird, kann er das Zertifikat bis zu dessen Ablauf weiter akzeptieren. Deshalb bleibt ein kurzes Gültigkeitsintervall auch beim Betrieb von Widerrufslisten sinnvoll.

Wenn Sie den privaten Schlüssel der CA selbst verdächtigen, ist der Widerruf einzelner Zertifikate die falsche Größenordnung. Entfernen oder ersetzen Sie auf den betroffenen Servern das Vertrauen in diese CA, stellen Sie eine neue CA aus und zertifizieren Sie nur die Zugänge neu, denen Sie weiterhin vertrauen. Verwenden Sie eine eigene CA für den Agentenzugriff, damit dieser Vorgang den Notfallzugang von Menschen nicht sperrt. Halten Sie einen getesteten Notfallpfad bereit, bewahren Sie ihn aber außerhalb der Reichweite des Agenten auf und protokollieren Sie seine Nutzung.

Beenden Sie schließlich aktive Sitzungen. Die Verteilung einer KRL blockiert künftige Authentifizierungen, beendet aber nicht unbedingt eine SSH-Verbindung, die der Server bereits akzeptiert hat. Nutzen Sie Host-Sitzungskontrollen, einen Job-Supervisor oder Netzwerkkontrollen, um laufende Arbeit zu stoppen. Prüfen Sie anschließend bereits ausgeführte Befehle, denn der Widerruf eines Zugangs kann kein Deployment rückgängig machen und keine gelöschte Datei wiederherstellen.

Eine Zertifikatsausstellungsstelle muss bei Unsicherheit sicher ablehnen

Die Ausstellungsstelle sollte eine Erneuerung ablehnen, wenn sie die Identität des lokalen Executors, den Sitzungsstatus, den angeforderten Principal oder die für diesen Umfang erforderliche Autorisierung nicht prüfen kann. Unter Verfügbarkeitsdruck machen Teams diese Prüfungen zu Warnungen. Damit wird aus einem vorübergehenden Ausfall eine unbeschränkte Ausstellung von Zugangsdaten.

Planen Sie die gewöhnlichen Fehlerfälle vor dem Einführungstag. Wenn die Ausstellungsstelle nicht erreichbar ist, lassen Sie ein bestehendes Zertifikat bis zu seinem normalen Ablauf funktionieren, ersetzen Sie es aber nicht stillschweigend durch einen statischen privaten Schlüssel. Wenn der lokale Tresor gesperrt ist, verweigern Sie die Aktion. Wenn eine menschliche Genehmigung erforderlich ist und niemand antwortet, lassen Sie die Arbeit ablaufen, statt dem Agenten eine Genehmigung auf unbestimmte Zeit zu überlassen.

Ein nützlicher Erneuerungsnachweis enthält den CA-Fingerabdruck, die Zertifikatsseriennummer, Ausstellungszeit, Ablaufzeit, Fingerabdruck des öffentlichen Schlüssels, angeforderten Principal, die Identität des Agentenprozesses, Sitzungskennung, Zielklasse und Genehmigungsergebnis. Das Zertifikat selbst enthält einen Teil dieser Informationen. Es zeigt jedoch nicht, ob die Anfrage dem vorgesehenen lokalen Kontrollpfad gefolgt ist.

Die Ausstellungsstelle sollte außerdem verhindern, dass der Umfang bei der Erneuerung ausweitet. Eine für deploy-prod genehmigte Sitzung darf nicht einfach in root-prod oder einen umfassenderen Principal erneuert werden, nur weil der Agent seinen Plan geändert hat. Für ein anderes Konto, eine andere Zielgruppe oder eine andere Befehlsklasse ist eine neue Autorisierungsgrenze erforderlich. Genau hier werden lang laufende autonome Jobs oft unsicher: Die Sitzung beginnt eng begrenzt und sammelt durch Erneuerungslogik, die niemand prüft, nach und nach Ausnahmen an.

Verwenden Sie getrennte Nachweise für Ausstellung und Ausführung. Die Ausstellung beweist, dass die CA ein Zertifikat autorisiert hat. SSH-Serverprotokolle und Aktivitätsaufzeichnungen des Executors zeigen, wo ein Zugang verwendet wurde und welcher Befehl lief. Sie brauchen beides, wenn ein Betreiber wissen möchte, ob ein Zertifikat falsch ausgestellt oder korrekt ausgestellt, aber missbraucht wurde.

Testen Sie den Widerruf als zeitlich gemessene Betriebsübung

Ein Ablaufplan mit der Anweisung «Zertifikat widerrufen» ist unvollständig, solange er nicht die Systeme, Dateien, Zugriffsrechte, das erwartete Scheitern und die Person benennt, die handeln kann, wenn die Ausstellungsstelle nicht erreichbar ist. Führen Sie die Übung an einem Nichtproduktionsziel mit echten Zertifikaten und demselben Verteilungsmechanismus durch, den Sie in der Produktion verwenden.

Verwenden Sie diese Reihenfolge:

1. Stellen Sie ein Zertifikat mit einer bekannten Seriennummer und einem kurzen, dokumentierten Intervall aus.
2. Authentifizieren Sie sich einmal und protokollieren Sie das serverseitige Akzeptanzereignis.
3. Deaktivieren Sie die Erneuerung für die zugehörige Agentensitzung.
4. Nehmen Sie das Zertifikat in die KRL auf, verteilen Sie sie, laden Sie die betroffenen sshd-Instanzen neu.
5. Versuchen Sie eine neue SSH-Verbindung und bestätigen Sie, dass der Server sie ablehnt. Beenden Sie anschließend die ursprüngliche aktive Sitzung, falls eine besteht.

Messen Sie die tatsächliche Zeit von der Eindämmungsanforderung bis zur Ablehnung in jeder Servergruppe. Veröffentlichen Sie keine Zielzahl, die Sie noch nie beobachtet haben. Die Dauer hängt davon ab, wie schnell Ihr Konfigurationssystem die KRL verteilt und wie zuverlässig es sshd neu lädt.

Testen Sie auch die unangenehmen Fälle. Widerrufen Sie ein Zertifikat, während ein Zielhost nicht erreichbar ist. Widerrufen Sie es während einer bestehenden Multiplexing-Verbindung. Widerrufen Sie es, während der lokale Rechner schläft und die Erneuerung nicht abgeschlossen werden kann. Widerrufen Sie es, nachdem ein Betreiber eine Sitzung genehmigt hat, aber vor dem ersten Befehl. Jedes Ergebnis zeigt, ob Ihre Kontrollen die Ausstellung, die neue Authentifizierung oder die aktive Ausführung blockieren. Das sind unterschiedliche Kontrollen. Wenn Sie alle als Widerruf bezeichnen, entstehen gefährliche Annahmen.

Bewahren Sie die Nachweise der Übung auf. Halten Sie das ausgestellte Zertifikat, die KRL-Änderung, den Executor-Nachweis und das Ablehnungsprotokoll des Zielservers vor. Wenn ein echter Vorfall eintritt, gibt dieses Paket den Einsatzkräften einen verifizierten Befehlsweg statt eines Dokuments, das zu Wunschdenken gealtert ist.

Genehmigung, Audit und SSH-Zugriff müssen verbunden bleiben

Eine menschliche Genehmigung ist nur dann sinnvoll, wenn sie dem Prozess zugeordnet ist, der sie verwenden wird. Die Genehmigung eines unbenannten Hintergrundprozesses lädt dazu ein, das Falsche zu bestätigen. Die prüfende Person sollte sehen, wer den Prozess signiert hat, welche Sitzung er startet und ob der angeforderte SSH-Zugang einen gewöhnlichen oder sensiblen Umfang hat.

Sallyport verwahrt SSH-Zugangsdaten in seinem verschlüsselten lokalen Tresor und führt SSH über seinen integrierten Helfer aus. Ein MCP-fähiger Agent benötigt den privaten SSH-Schlüssel daher nicht in seiner eigenen Umgebung. Sitzungs- und Aktivitätsjournale können eine menschliche Genehmigung mit dem Agentenprozess und den nachfolgenden Aktionsaufzeichnungen verbinden.

Die Prüfspur braucht neben einer bequemen Ansicht auch einen Manipulationsnachweis. Sallyport erstellt seine Journale aus einem verschlüsselten, hashverketteten Auditprotokoll. Mit sp audit verify kann ein Betreiber diese Kette offline prüfen, ohne auf den Tresor zugreifen zu müssen. Führen Sie diese Prüfung bei der Untersuchung eines Vorfalls und beim Export von Nachweisen aus. Eine lesbare Aktivitätsliste allein beweist nicht, dass niemand ein unangenehmes Ereignis entfernt hat.

Machen Sie das Auditsystem nicht für Zugriffsrichtlinien verantwortlich, die es nicht durchsetzt. Der SSH-Server muss weiterhin der richtigen CA vertrauen, nur die vorgesehenen Principals akzeptieren, die aktuelle KRL einlesen und das Zielkonto einschränken. Der lokale Executor muss private Zugänge weiterhin schützen und die von Ihnen vorgesehenen Genehmigungen einholen. Protokolle liefern Nachweise und betriebliche Rückmeldungen. Sie reparieren kein Konto mit übermäßigen Berechtigungen.

Der beste erste Schritt ist nicht eine noch kürzere Zertifikatslaufzeit. Ermitteln Sie, welche Agentenaktionen SSH benötigen, geben Sie jeder einen eng gefassten Principal und ein passendes Konto, verwahren Sie den privaten Zugang lokal und üben Sie den Ablauf, der die Ausstellung stoppt, den Widerruf verteilt und aktive Sitzungen beendet. Wenn das funktioniert, wählen Sie die kürzeste Zertifikatslaufzeit, die Ihr tatsächliches Erneuerungssystem zuverlässig tragen kann.