Zusammenfassung

  • Eine Signaturanforderung nach RFC 9987 bezeichnet einen öffentlichen Schlüssel, übergibt Daten und Flags und erhält eine Signatur oder einen Fehler. Vorgeschriebene Angaben über Prozess, Person, Zielsystem, Konto oder Zweck gehören nicht zu diesem Beleg.
  • Das Agentenprotokoll authentifiziert den Client nicht selbst und schützt seinen Transport nicht. Meist entscheidet der Zugriff auf den lokalen Endpunkt darüber, wer Schlüsseloperationen auslösen kann; Weiterleitung erweitert diesen Kreis über eine Vertrauensgrenze.
  • Lebensdauer, Bestätigung, Sperrzustand, Agentenergebnis, Serverauthentifizierung und Anwendungsberechtigung sind eigenständige Urteile. Daniel Kade schlägt einen datensparsamen, sechsstufigen Signierabsichtsbeleg vor.

Der Schlüssel blieb liegen, seine Handlungsmacht nicht

Ein Prüfbericht kann drei richtige Sätze enthalten: Der Agent hat die Anfrage erfolgreich beantwortet. Die Signatur ist kryptographisch gültig. Das private Schlüsselmaterial hat den geschützten Prozess oder das Hardwaremodul nie verlassen. Daraus folgt noch nicht, dass die Handlung erlaubt war. Vielleicht stammte die Anfrage von einem fremden lokalen Prozess, vielleicht von einem weitergeleiteten Agentenkanal auf einem kompromittierten Host. Vielleicht zeigte eine Bestätigung nur einen Fingerabdruck und kein verständliches Ziel.

Der im Mai 2026 als IETF Proposed Standard veröffentlichte RFC 9987 beschreibt den Austausch zwischen einem Client und einem Agenten, der private Schlüssel verwahrt oder deren Nutzung delegiert. Der Client stößt die Vorgänge an: Identitäten hinzufügen, entfernen oder auflisten, Signaturen anfordern, den Agenten sperren oder Erweiterungen verwenden. Die Spezifikation gibt einer verbreiteten Schnittstelle klare Paket- und Fehlerregeln. Sie erklärt nicht jede institutionelle Bedeutung der signierten Daten.

SSH_AGENTC_SIGN_REQUEST trägt den öffentlichen Schlüsselblob, eine Datenfolge und Flags. Bei Erfolg folgt SSH_AGENT_SIGN_RESPONSE mit der Signatur. Pflichtfelder für einen ausführenden Prozess, einen Menschen, einen Zielhost, ein entferntes Konto, einen Befehl, einen Freigabebeleg oder einen Geschäftszweck gibt es nicht. Selbst wenn die Daten Teil einer SSH-Anmeldung sind, hat die generische Agentennachricht keinen vollständigen Blick auf deren Folgen.

Diese schmale Zuständigkeit ist sinnvoll. Interoperabilität verlangt nicht, dass der Agent zum universellen Policy-System wird. Der Governance-Fehler beginnt erst, wenn ein Dashboard aus „Signatur erzeugt“ die Aussage „Nutzer hat zugestimmt“ ableitet. Why BTW Media Exists trennt beobachtbare Wirklichkeit von nachträglicher Behauptung. Beobachtet wurde hier eine Schlüsseloperation. Für Zustimmung und Berechtigung braucht es zusätzliche Evidenz.

Verwahrung und Nutzung sind zwei Kontrollflächen

RFC 9987 stellt klar, dass das Agentenprotokoll weder Clientauthentifizierung noch Transportsicherheit mitbringt. Üblicherweise wird es über einen lokalen Socket oder eine Named Pipe geführt, deren Rechte das Betriebssystem schützen soll. Wer den Endpunkt erreicht, kann meist Operationen mit sichtbaren Schlüsseln anfordern. Damit ist die Zugangskontrolle zum Kanal ebenso wichtig wie die Absicherung des Schlüsselmaterials.

Ein Angreifer muss den Schlüssel nicht kopieren können, um ihn zu missbrauchen. Ein erreichbarer, unbeschränkter Agent kann fremde Daten signieren und sogar als besonders geeigneter Beobachtungsoracle für Seitenkanäle dienen. Nicht exportierbar heißt deshalb: Der geheime Wert blieb an seinem Ort. Es heißt nicht: Nur berechtigte Zwecke konnten seine Wirkung auslösen.

Bei Hardwaretoken führt ungenaue Sprache leicht zu falscher Entwarnung. Eine im Agenten geladene Identität kann Operationen an das Token delegieren. Wird sie aus dem Agenten entfernt, sollte der Schlüssel auf dem Token bestehen bleiben. Der Satz „Schlüssel gelöscht“ muss also die betroffene Schicht benennen. Sonst schließt die Einsatzleitung einen Vorgang, obwohl die Identität später erneut geladen werden kann.

The Policy Mirror legt nahe, die Policy an die wirkliche Verteilung von Kontrolle zu binden. Das Betriebssystem kontrolliert den Agentenzugang. Der Agent setzt Lebensdauer und Bestätigung um. Das Token kontrolliert das Material und gegebenenfalls lokale Präsenz. Der SSH-Server bewertet den Authentikator für ein Konto. Die Anwendung entscheidet über Handlungen nach der Anmeldung. Keine Schicht darf ihr Ergebnis für das Gesamturteil ausgeben.

Beschränkungen brauchen eine Epoche

Beim beschränkten Laden kann eine Lebensdauer angegeben werden; danach soll der Agent die Identität entfernen. Eine Bestätigungsbeschränkung fordert vor jeder privaten Schlüsseloperation eine ausdrückliche Zustimmung. Benannte Erweiterungen können weitere Grenzen tragen. Versteht der Agent eine angeforderte Beschränkung nicht, muss der Ladevorgang scheitern. Stilles Weglassen würde den Schutz gerade dort aufheben, wo der Client ihn erwartet.

Doch auch korrekt verstandene Beschränkungen sind veränderlicher Zustand. Wird derselbe Schlüssel erneut hinzugefügt, soll die neue Anfrage die bisherigen Beschränkungen ersetzen; alternativ kann der Agent die Aufnahme verweigern. Ein Fingerabdruck sagt daher nichts darüber, welche Regeln in der Minute einer Signatur galten. Ein belastbarer Beleg braucht eine Lade- oder Ersetzungsepoche und muss die Operation mit der damals wirksamen Lebensdauer, Bestätigung, Erweiterung und Sperre verbinden.

Auch das Wort Bestätigung trägt nicht automatisch Zustimmung. Ein Klick beweist nur, dass eine Oberfläche eine positive Antwort bekam. Informierte Zustimmung verlangt, dass diese Oberfläche Ziel, Konto, Protokoll und Folge verständlich und wahrheitsgemäß zeigte. Rohdaten können zu sensibel sein; eine Meldung wie „Schlüsselnutzung erlauben?“ ist dagegen zu inhaltsarm. Ein sicherer Kontextbeleg muss deshalb eine verständliche Darstellung mit einem Hash der tatsächlich signierten Daten verbinden.

Die Agentensperre ist ein eigener Zustand. Im gesperrten Zustand sind mindestens private Signaturen auszusetzen, bis das richtige Geheimnis den Agenten entsperrt. Das Entsperren gibt eine Fähigkeit wieder frei. Es identifiziert weder spätere Clients noch genehmigt es alle Ziele. Wer es als pauschale Zustimmung behandelt, dehnt einen lokalen Zustandswechsel auf unbekannte künftige Vorgänge aus.

Weiterleitung ist transitives Vertrauen

Agentenweiterleitung vermeidet, dass ein entfernter Rechner den privaten Schlüssel erhält. Trotzdem erhält er unter Umständen die Fähigkeit, den lokalen Agenten zu einer Operation zu bewegen. RFC 9987 nennt dies eine transitive Vertrauensbeziehung, empfiehlt die Funktion nicht standardmäßig einzuschalten und warnt vor der Weiterleitung auf nicht vollständig vertrauenswürdige Hosts. Das Schlüsselmaterial bleibt daheim, aber sein Aufrufrecht reist.

Die Kanalstruktur begrenzt die Zuschreibung. agent-connect enthält keine Kennung für den Sitzungskanal, aus dem die Verbindung stammt. Eine SSH-Verbindung kann mehrere Sitzungen tragen; der lokale Agent kann mehrere weitergeleitete Verbindungen zugleich sehen. Die Aussage „kam über diesen Transport“ muss daher nicht genügen, um einen bestimmten Shellprozess oder Menschen zu identifizieren.

Running Code Primary verlangt Evidenz aus den tatsächlich laufenden Grenzen. Relevant sind Socketrechte, Peerinformationen, die konkrete Weiterleitungsentscheidung, die aktive Beschränkungsepoche, Zeitkorrelation und das Ergebnis auf der Gegenseite. Eine Konfigurationsvorgabe ohne diese Beobachtungen kann den Pfad einer alten Signatur nicht rekonstruieren.

Der Server trifft sein eigenes Urteil

Im RFC 4252 liegt die Public-Key-Authentifizierung beim Server. Die Signatur bindet unter anderem die Sitzungskennung, Nutzername, Dienst, Methode, Algorithmus und öffentlichen Schlüssel. Der Server muss prüfen, ob der Schlüssel für den verlangten Nutzer akzeptabel ist, und die Signatur verifizieren. Er kann weitere Faktoren verlangen. Erst SSH_MSG_USERAUTH_SUCCESS markiert die vollständige Authentifizierung; die Agentenantwort tut das nicht.

Der RFC 4253 liefert den geschützten Transport und die Sitzungskennung, der RFC 4254 regelt Kanäle und Dienste, und der RFC 4251 beschreibt die Gesamtarchitektur. Schlüsselgebrauch, Kontoauthentifizierung und spätere Befehlsberechtigung bleiben dadurch getrennte Tatsachen.

Auch die Algorithmenregister beantworten nur Interoperabilitätsfragen. RFC 8332 beschreibt RSA-Signaturen mit SHA-2, RFC 8709 Ed25519 und Ed448, RFC 8308 Erweiterungsverhandlung. Die IANA-Registry für SSH-Parameter ordnet gemeinsame Namen zu. Registrierung beweist weder Einsatz noch Zustimmung oder Autorisierung.

Sechs Stationen für einen Signierabsichtsbeleg

Der erste Belegteil erfasst die Aufnahme des Anforderers: lokal oder weitergeleitet, minimal verfügbare Peer-Evidenz, Policy-Epoche und eine opake Vorgangskennung. Der zweite erfasst den Schlüsselzustand: öffentlicher Fingerabdruck, Sichtbarkeit, Ladeepoche, Lebensdauer, Bestätigung, Erweiterungen, Token-Delegation und Sperrzustand.

Der dritte Teil beschreibt die Operation mit Länge und kollisionsfestem Hash der exakten Daten, Algorithmus und Flags, nicht mit dem geheimen Klartext. Der vierte hält fest, ob Bestätigung verlangt wurde, welcher sichere Kontext erschien, welche vertrauenswürdige Oberfläche entschied und ob sie zustimmte, ablehnte oder nicht verfügbar war. Der fünfte enthält Erfolg oder Fehler des Agenten. Der sechste enthält Protokoll, Ziel, Sitzung, angefordertes Konto, Serverprüfung, weitere Faktoren und die spätere Berechtigung.

Dieser Aufbau ist Daniel Kades Governance-Vorschlag und keine Vorgabe des RFC 9987. Er erweitert nicht die Verantwortung des Agenten, sondern verhindert, dass dessen enges Ergebnis die gesamte Autoritätskette verdeckt.

Quellen