Zusammenfassung

  • RFC 9987 standardisiert einen Agenten, der private Schlüssel hält und Anfragen zum Laden, Entfernen, Auflisten, Sperren und Signieren beantwortet. Das Basisprotokoll authentisiert den Client nicht; Zugriff auf den Endpunkt ist regelmäßig die wirksame Erlaubnis.
  • Weiterleitung kopiert den privaten Schlüssel nicht zum entfernten Host. Sie verlängert den Weg für private Operationen und erzeugt damit die transitive Vertrauensbeziehung, vor der der RFC ausdrücklich warnt.
  • Lebensdauer, Bestätigung und Erweiterungsbeschränkungen können den Aufruf einschränken. Der Zielserver entscheidet weiterhin separat über Schlüssel, Konto, Signatur, weitere Faktoren, Kanäle und Wirkung.

Die klassische Erfolgsmeldung lautet: Der Schlüssel hat den Arbeitsplatz nie verlassen. Diese Aussage kann technisch einwandfrei sein. Ein Angreifer auf dem Sprungserver hat weder Seed noch Primfaktoren gelesen, keinen Schlüssel exportiert und keine Kopie auf Festplatte hinterlassen.

Trotzdem kann er den Schlüssel benutzt haben. Wenn der weitergeleitete Socket erreichbar war, konnte ein Prozess eine Signaturanfrage stellen. Der Agent am Arbeitsplatz führte die private Operation aus. Ein anderer Server konnte die Signatur für ein dort autorisiertes Konto akzeptieren.

Die materielle Verwahrung blieb korrekt. Die aufrufbare Befugnis war weitergereicht.

Ein kleiner gemeinsamer Vertrag

RFC 9987 erschien im Mai 2026 als Proposed Standard. Er beschreibt ein clientgetriebenes Anfrage-Antwort-Protokoll. Der Agent sendet nichts unaufgefordert und antwortet in Reihenfolge. Clients können Identitäten abfragen, Schlüssel laden oder löschen, den Agenten sperren und Signaturen erzeugen lassen. Der Agent darf Typen und Operationen ablehnen.

Die Architektur bietet echte Sicherheit. SSH-Prozesse müssen nicht jeweils einen entschlüsselten privaten Schlüssel halten. Ein kleiner Agent kann Debugging und Dumps verhindern, Token-Code isolieren und Passphrasen seltener anfordern. Nicht exportierbare Hardware-Schlüssel können im Gerät bleiben.

Der gemeinsame Vertrag liefert jedoch weder Authentisierung noch Transportschutz für das Agent-Protokoll. Unter Unix begrenzen Socket-Rechte und Peer-Credentials den Zugang; unter Windows kann ein Sicherheitsdeskriptor die Named Pipe schützen. SSH_AUTH_SOCK weist Clients auf den Endpunkt.

Damit ist der Endpunkt selbst eine Autoritätsfläche. Wer ihn erreichen kann, kann üblicherweise private Operationen anfragen. RFC 9987 unterscheidet ausdrücklich zwischen dem Diebstahl des Schlüssels und dem Diebstahl seiner Nutzung.

Eine Signaturanfrage enthält Public-Key-Blob, Daten und Flags. Eine erfolgreiche Antwort beweist, dass der Agent unter seinen aktuellen Regeln signiert hat. Sie beweist nicht, dass der anfragende Prozess ein Mandat hatte, die Daten einen genehmigten Zielkontext darstellten, ein Server die Signatur akzeptierte oder ein Befehl ausgeführt wurde.

Beschränkungen müssen wirksam sein

Die Lebensdauerbeschränkung löscht den Schlüssel nach einer Zahl von Sekunden seit dem Laden. Sie schließt künftige Aufrufe an diesem Agenten. Bereits ausgestellte Signaturen, angenommene Sitzungen und ausgeführte Änderungen bleiben bestehen.

Die Bestätigungsbeschränkung verlangt vor jeder privaten Operation eine ausdrückliche Entscheidung. Der RFC normiert weder Dialog noch angezeigten Kontext. Eine Bestätigung mit Ziel, Konto und Anfrage ist aussagekräftiger als ein Fenster mit bloßem Schlüsselkommentar. Bei hoher Frequenz droht Bestätigungsmüdigkeit.

Erweiterungsbeschränkungen können implementierungsspezifische Regeln tragen. Versteht der Agent eine Beschränkung nicht, muss er die Verarbeitung abbrechen und den Schlüssel ablehnen. Er darf die unbekannte Grenze nicht stillschweigend ignorieren. Dieses Fail-closed-Verhalten schützt die Absicht, ersetzt aber keinen Interoperabilitätstest.

Beschränkungen sind veränderlicher Zustand. Wird ein bereits vorhandener Schlüssel erneut hinzugefügt, sollte der Agent die alten Bedingungen durch die neuen ersetzen oder das Duplikat ablehnen. Ein Neustart oder anderes Werkzeug kann daher aus einem kurzlebigen, bestätigungspflichtigen Schlüssel einen unbeschränkten machen. Maßgeblich ist der gelesene Zustand nach jeder Transition.

Das Sperren des Agenten stoppt sensible Operationen bis zur Entsperrung. Es beendet nicht rückwirkend Sitzungen auf anderen Servern.

Transitives Vertrauen ist breiter als Hostvertrauen

Bei Agent-Weiterleitung stellt die entfernte Seite einen Socket bereit. Nachrichten laufen über einen SSH-Kanal zurück zum clientseitigen Agenten. Der private Schlüssel wird nicht übertragen. Die Möglichkeit, ihn arbeiten zu lassen, wird übertragen.

RFC 9987 nennt das eine inhärente transitive Vertrauensbeziehung. Implementierungen sollten nicht standardmäßig weiterleiten; Nutzer sollten nicht zu Hosts weiterleiten, denen sie nicht vollständig vertrauen. Ohne zusätzliche Kontrolle über Sichtbarkeit und Verwendung der Schlüssel bleibt nur Alles oder Nichts.

Vollständiges Vertrauen umfasst mehr als die Prüfung des Hostkeys. Es umfasst privilegierte Prozesse, Administratoren, Erweiterungen, benachbarte Workloads, Softwarelieferkette und Erkennung. Ein Bastion-Host kann den Netzzugang bündeln und gleichzeitig die aufrufbare Macht vieler Agenten konzentrieren.

Die Protokollform liefert keine perfekte Zuordnung. Ein SSH-Transport kann mehrere Sessions und parallele Agent-Verbindungen tragen. agent-connect nennt nicht den Ursprungskanal. Ein Client darf nach eigener Autorisierung Verbindungen ohne vorangegangene Session-Anfrage annehmen und auch nach deren Ende fortsetzen.

Deshalb muss die Beweiskette äußere Verbindung, Weiterleitungsanfrage, Agent-Kanal, Schlüssel, Beschränkung, Signatur und Zielauthentisierung verbinden. Gleichzeitigkeit allein ist keine Kausalität.

Der Zielserver urteilt selbst

RFC 4252 bindet die Public-Key-Signatur an Session-Identifier, Benutzer, Dienst, Methode, Algorithmus und Schlüssel. Der Zielserver prüft, ob der Schlüssel für das Konto zugelassen und die Signatur korrekt ist. Weitere Authentisierung kann folgen.

Eine einzelne Signatur ist somit kein universelles Passwort. Doch solange der Agent erreichbar bleibt, kann ein Angreifer eine neue Signatur für eine neue korrekt gebildete Sitzung verlangen. Replay-Schutz ist nicht gleich Schutz vor missbrauchter Online-Fähigkeit.

Getrennt bleiben müssen: Schlüssel geladen; Endpunkt erreichbar; Agent signiert; Signatur bindet Kontext; Server akzeptiert; Kanal erhält Rechte; Wirkung tritt ein. Jede Stufe hat andere Evidenz.

Auch Algorithmusmengen unterscheiden sich. Agent, Client, Server und Organisationsrichtlinie können RSA, Ed25519 und RSA/SHA-2 verschieden behandeln. IANA-Registrierung koordiniert Werte, beweist aber keine Aktivierung oder Konformität.

Eine belastbare Ereigniskette

Am Ursprung sind Agent-Prozess, Endpunktrechte, Peer-Identität, Fingerprint, Ladezeit, effektive Beschränkungen, Sperre und Entfernung zu erfassen. Bei Token-Schlüsseln gehören Provider-Bibliothek und Isolation dazu.

An der Weiterleitung braucht es äußere Verbindung, Hostvertrauen, Anfrage, alle Agent-Kanäle und deren Ende. Verbindungen nach Session-Ende sowie explizite, geerbte oder opportunistische Konfiguration sind getrennt zu behandeln.

Für jede Operation sind Zeit, Schlüssel, Algorithmus, sicherer Fingerprint des Kontexts, Beschränkungsentscheidung und angezeigte Bestätigung zu sichern. Der Zielserver liefert Konto, zugelassenen Schlüssel, Ergebnis, weitere Faktoren, Kanäle und Einschränkungen.

Danach folgt die Wirkung: Befehl, Subsystem, Portweiterleitung, Dateioperation oder Ablehnung. Abschluss bedeutet Schlüssel entfernen, Agent und Kanäle schließen, Zielberechtigungen nötigenfalls entziehen und einen neuen Versuch scheitern sehen.

„Kein Schlüsselabfluss“ ist dann ein genauer Teilbefund, nicht länger ein vorzeitiger Freispruch.