Risiken der SSH-Agent-Weiterleitung bei KI-gestützter Entwicklung

Die Risiken der SSH-Agent-Weiterleitung werden leicht unterschätzt, weil der private Schlüssel auf dem Rechner des Entwicklers bleibt. Das stimmt, reicht aber nicht aus. Ein Remote-Host, der einen weitergeleiteten Agent-Socket erhält, kann den lokalen Agent auffordern, SSH-Authentifizierungsanfragen zu signieren. Für jedes System, das diese Identität akzeptiert, kann der Remote-Host so lange wie der Zugriff besteht als du auftreten.

KI-gestützte Entwicklung macht diesen Fehler wahrscheinlicher und schwerer erkennbar. Ein Coding-Agent kann Remote-Shells öffnen, Deployment-Befehle ausführen, Repositories untersuchen und eine SSH-Konfiguration verwenden, die du vor Jahren für eine interaktive Sitzung geschrieben hast. Erreicht der Agent einen Rechner mit deinem weitergeleiteten Socket, hat sich die Sicherheitsgrenze bereits verschoben. Deaktiviere die Weiterleitung standardmäßig und gib Remote-Jobs eigene, eng begrenzte Identitäten, wenn sie wirklich einen weiteren Hop benötigen.

Ein weitergeleiteter Agent kann über den ersten Host hinaus authentifizieren

SSH-Agent-Weiterleitung stellt einen Signierdienst bereit, keine Kopie des privaten Schlüssels. Dein lokaler ssh-agent verwaltet eine oder mehrere private Identitäten. Wenn du die Weiterleitung aktivierst, legt SSH auf dem Remote-Rechner einen Socket an und leitet Signieranfragen über die verschlüsselte Verbindung an den lokalen Agent weiter.

Dieser Unterschied führt oft zu falschen Risikoeinschätzungen. Viele hören «Der Schlüssel verlässt meinen Laptop nie» und schließen daraus, dass auf dem Remote-Rechner nichts Angreifbares vorhanden ist. Die privaten Bytes können lokal bleiben, doch SSH benötigt für die Authentifizierung nicht deren Besitz auf dem Remote-Rechner. Es braucht eine gültige Signatur über eine Authentifizierungsanfrage. Der weitergeleitete Socket bietet eine Möglichkeit, diese Signatur zu erhalten.

Das OpenSSH-Handbuch ssh_config(5) beschreibt ForwardAgent eindeutig und warnt, dass Benutzer, die Dateiberechtigungen auf dem Remote-Host umgehen können, auf den weitergeleiteten Agent zugreifen können. In der Praxis bedeutet das: Das Remote-Konto selbst, ein Prozess unter diesem Konto, ein Administrator oder ein Angreifer mit ausreichender Kontrolle kann den Socket verwenden. Root-Zugriff auf dem Remote-Host beendet jede Diskussion über Socket-Berechtigungen.

RFC 4252 beschreibt die Public-Key-Authentifizierung von SSH als Signatur über verbindungsspezifische Daten. Der Server prüft diese Signatur gegen einen autorisierten öffentlichen Schlüssel. Ein kompromittierter Remote-Host kann den Agent nicht in einen allgemeinen Signierdienst für beliebige Dokumente verwandeln. Er kann aber die SSH-Signaturen anfordern, die für Anmeldeversuche bei anderen Systemen nötig sind. Genau diese Fähigkeit ist für einen Angreifer wertvoll, wenn deine Identität bei der Quellcodeverwaltung, auf Produktionshosts oder in internen Administrationssystemen funktioniert.

Der typische Fehler sieht so aus:

1. Ein Entwickler verbindet sich mit build.example.net über ssh -A, weil dieser Rechner ein privates Repository erreichen muss.
2. Der lokale Agent des Entwicklers erscheint auf dem Build-Host über SSH_AUTH_SOCK.
3. Ein Build-Skript, eine kompromittierte Abhängigkeit oder ein anderer Benutzer mit ausreichenden Rechten bittet diesen Socket, für git.example.net oder einen internen Host zu signieren.
4. Das Ziel akzeptiert den öffentlichen Schlüssel des Entwicklers und protokolliert die neue Verbindung als Verbindung des Entwicklers.

Der SSH-Server am Ziel sieht eine gültige kryptografische Signatur. Er kann nicht erkennen, ob ein Mensch die Verbindung auf seinem Laptop gestartet hat oder ob ein Prozess auf dem ersten Remote-Rechner sie über die Weiterleitung angefordert hat. Serverprotokolle nennen den akzeptierten Schlüssel und die Quelladresse, stellen diese verlorene Unterscheidung aber nicht wieder her.

Konfigurationsvererbung führt zu unbeabsichtigter Offenlegung

Die meisten unsicheren Weiterleitungen beginnen in der SSH-Konfiguration, nicht mit einer bewussten Entscheidung während einer riskanten Sitzung. Ein einzelner alter Block wie Host * mit ForwardAgent yes kann für jeden Host gelten, den ein Entwickler, ein Terminal-Tool oder ein Coding-Agent kontaktiert. Das gilt auch, wenn ein Tool SSH aus einem Skript aufruft und niemand eine Warnung sieht.

Die OpenSSH-Konfiguration hat eine weitere Schwachstelle: Für jeden Parameter verwendet der Client normalerweise den ersten Wert, den er findet. Eine allgemeine Regel vor einer engeren Regel kann die Ausnahme unwirksam machen, die du zu konfigurieren glaubtest. Verlasse dich nicht auf einen kurzen Blick in ~/.ssh/config. Frage SSH, welche Konfiguration tatsächlich verwendet wird.

Führe dies vor der Verbindung auf dem lokalen Rechner aus:

ssh -G deploy.internal.example | grep '^forwardagent '

Ein sicheres Ergebnis ist:

forwardagent no

ssh -G gibt die effektive Client-Konfiguration aus, nachdem Dateien und Befehlszeilenoptionen verarbeitet wurden. Es öffnet keine Verbindung. Dadurch eignet es sich für Prüfungen beim Einrichten und für ein Testskript, das eine Liste sensibler Hosts durchgeht.

Setze am Ende der relevanten Konfigurationsdatei eine ausdrückliche Standardregel zum Verbieten. Eng begrenzte Ausnahmen müssen davor stehen, weil OpenSSH den ersten passenden Wert nimmt:

Host docs-bastion.example
    ForwardAgent yes

Host *
    ForwardAgent no

Dieses Beispiel gewährt weiterhin eine gefährliche Ausnahme. Sie braucht deshalb einen konkreten Grund und einen Verantwortlichen. Der Zweck ist, die Ausnahme sichtbar auf einen Host zu begrenzen, statt sie unbemerkt auf jede neue Umgebung anzuwenden.

Für eine einmalige Verbindung kannst du die sichere Einstellung erzwingen, selbst wenn die Konfigurationsdatei etwas anderes vorgibt:

ssh -o ForwardAgent=no [email protected]

Das kürzere ssh -a [email protected] erledigt dasselbe. Nutze eine dieser Varianten, wenn du dich mit einem ungeprüften Rechner, einem temporären Support-Host, einer Schulungsumgebung oder einem von einem Anbieter verwalteten System verbindest.

Verwechsle IdentitiesOnly yes nicht mit einer Einstellung für die Weiterleitung. Diese Option beeinflusst, welche Identitäten der SSH-Client bei der Authentifizierung an einen Server anbietet. Sie verhindert nicht, dass SSH auf der Remote-Seite einen Agent-Socket anlegt. Ebenso ist das Entfernen von SSH_AUTH_SOCK aus einer einzelnen Shell keine vollständige Richtlinie. Ein Kindprozess kann eine andere Umgebung übernehmen, und eine SSH-Konfiguration kann die Weiterleitung bei der nächsten Verbindung wieder aktivieren.

KI-Workflows vervielfachen die zu prüfenden Wege

Ein KI-Coding-Agent braucht keine böswillige Absicht, damit Weiterleitung gefährlich wird. Es genügt, wenn er einen Befehl ausführen darf, der auf deine bestehenden SSH-Gewohnheiten trifft. Agents befolgen Anweisungen aus Repositories, starten Build-Skripte, verwenden Remote-Entwicklungsrechner und wiederholen Befehle mit kleinen Änderungen. Das sind normale Verhaltensweisen. Riskant werden sie, wenn die Umgebung ihnen eine wiederverwendbare Entwickleridentität gibt.

Der problematische Weg ist oft indirekt. Dein lokaler Agent startet eine SSH-Sitzung zu einem Entwicklungsrechner. Diese Sitzung leitet deinen Agent wegen einer globalen Konfigurationsregel weiter. Der Coding-Agent führt auf dem Entwicklungsrechner ein Repository-Skript aus. Das Skript lädt eine Abhängigkeit herunter oder öffnet eine zweite SSH-Verbindung. Diese zweite Verbindung kann den Socket verwenden, den deine erste Sitzung dort hinterlegt hat.

Das ist gefährlicher als ein Mensch, der einen einzelnen Befehl wie git fetch eingibt, weil ein Agent viele Tool-Aufrufe ausführen kann, ohne zu hinterfragen, warum eine Remote-Shell Zugriff auf ein unabhängiges Ziel benötigt. Außerdem kann der Agent in einem Repository auf Anweisungen stoßen, die ihn zur Verwendung eines bestimmten Host-Alias auffordern. Dieser Alias kann einen ProxyCommand-, eine Match-Regel oder eine geerbte Weiterleitungsregel vor dem Bediener verbergen.

Behandle diese Berechtigungen getrennt:

• Berechtigung eines Agents, eine Remote-Shell zu öffnen.
• Berechtigung dieser Remote-Shell, ein weiteres SSH-Ziel zu erreichen.
• Berechtigung des zweiten Ziels, die Identität des Entwicklers zu akzeptieren.
• Berechtigung des Agents, die zweite Verbindung auszulösen.

Teams fassen alle vier regelmäßig in «Der Agent braucht SSH» zusammen. Dieser Satz beschreibt die Grenze nicht. Eine Remote-Shell und eine wiederverwendbare Signierfähigkeit haben unterschiedliche Folgen und benötigen getrennte Entscheidungen.

Prüfe, wie der Agent-Prozess gestartet wird. Wenn er SSH_AUTH_SOCK von einem interaktiven Terminal übernimmt, kann er bereits Zugriff auf lokale Agent-Identitäten für direkte SSH-Authentifizierung haben. Verbindet er sich anschließend mit einem Host, auf dem die Weiterleitung aktiviert ist, erhält dieser Host einen zweiten Weg zu denselben Identitäten. Ein Wrapper, der die Umgebungsvariable löscht, kann die versehentliche lokale Verwendung reduzieren. Er ersetzt jedoch weder eine sichere SSH-Konfiguration noch eine eigene Identität für Automatisierung.

Prüfe außerdem Agent-Anweisungen und Automatisierungs-Wrapper auf ssh -A, scp -A oder Aliase, die diese Optionen erweitern. scp und sftp verwenden SSH-Transporteinstellungen, daher kann sich eine Weiterleitungsgewohnheit weiter verbreiten als der Befehl, der sie ursprünglich erzeugt hat. Lege die Entscheidung zur Weiterleitung dort fest, wo sie hingehört: in der Verbindungsdefinition, mit dem ausdrücklichen Standardwert «nein».

Ein Jump-Host braucht deinen Agent nicht

Viele Entwickler aktivieren die Weiterleitung, weil sie über einen Bastion-Host ein internes System erreichen müssen. Das war ein vertrautes Muster, als «Beim Bastion-Host anmelden und dann erneut SSH verwenden» die bequemste Lösung war. Es bleibt beliebt, weil es beim Einrichten schnell funktioniert. Gleichzeitig wird der Bastion-Host zu einem Rechner, der deine Identität wiederverwenden kann.

Verwende ProxyJump, wenn der erste Host nur Datenverkehr weiterleiten muss. Der lokale Client kann sich am endgültigen Host authentifizieren und die Verbindung durch den Jump-Host tunneln, ohne diesem Host einen Agent-Socket bereitzustellen.

Host engineering-bastion
    HostName bastion.example
    User developer
    ForwardAgent no

Host release-host
    HostName release.internal.example
    User deploy
    ProxyJump engineering-bastion
    ForwardAgent no

Bei dieser Konfiguration baut der lokale SSH-Client die endgültige SSH-Verbindung über den Bastion-Host auf. Der Bastion-Host transportiert verschlüsselten Datenverkehr. Er erhält keinen entfernten SSH_AUTH_SOCK, über den er Signaturen bei deinem Agent anfordern könnte.

Teste den Weg, statt anzunehmen, dass die Konfiguration das Gewünschte bewirkt:

ssh -vvv release-host

Suche in der Debug-Ausgabe nach der ProxyJump-Verbindung und prüfe, dass keine Agent-Weiterleitung gemeldet wird. Untersuche nach der Anmeldung am endgültigen Host die Remote-Umgebung:

printf 'SSH_AUTH_SOCK=%s\n' "${SSH_AUTH_SOCK:-}"
ssh-add -l

Eine leere Socket-Variable ist das erwartete Ergebnis, wenn du die Weiterleitung bewusst deaktiviert hast. Wenn ssh-add -l meldet, dass keine Verbindung zu einem Authentifizierungsagent besteht, passt das ebenfalls zu einem nicht weitergeleiteten Agent. Führe diese Prüfungen bei der Fehlersuche nicht nur auf dem endgültigen Host aus. Prüfe jeden interaktiven Hop, an dem jemand die Weiterleitung aktiviert haben könnte.

Es gibt berechtigte Fälle, in denen sich der Jump-Host selbst bei einem weiteren Host authentifizieren muss, etwa bei einem kontrollierten Release-Vorgang. Dann benötigt der Jump-Host eine eigene Deployment-Identität oder eine kurzlebige Workload-Identität. Er sollte nicht jede Identität ausleihen, die gerade im Agent des Entwickler-Laptops geladen ist.

Remote-Automatisierung braucht eine eigene Identität

Ein Remote-Build-Rechner, ein Deployment-Host oder ein KI-Tool sollte sich als die ihm zugewiesene Workload authentifizieren, nicht als der Entwickler, der die Sitzung zufällig gestartet hat. Diese Designänderung beseitigt den Bedarf an Weiterleitung, statt sie nur unbequemer zu machen.

Eine Workload-Identität sollte ausschließlich Zugriff auf die Dienste gewähren, die diese Workload benötigt. Verwende für ein Quellcode-Repository eine auf das Repository begrenzte Deploy-Identität, sofern der Dienst dies unterstützt. Für ein SSH-Ziel autorisiere einen eigenen öffentlichen Schlüssel für ein eigenes Konto und begrenze Befehle oder Berechtigungen dieses Kontos, wenn der Server solche Einschränkungen unterstützt. Bei zertifikatsbasiertem SSH stelle kurzlebige Zertifikate mit Principals aus, die zur Rolle der Workload passen.

SSH-Zertifikate können den Zugriff begrenzen, sind aber kein Wundermittel. Ein Principal steuert nur dann, welche Konten das Zertifikat akzeptieren, wenn der Server Principals korrekt prüft. Eine kurze Gültigkeitsdauer begrenzt, wie lange eine Signatur zur Authentifizierung verwendet werden kann. Ein kompromittierter Prozess kann sie während dieses Zeitraums trotzdem nutzen. Prüfe die Serverkonfiguration, die der Zertifizierungsstelle vertraut, sowie die Kontoregeln, die diese Principals verwenden.

Verwende nicht den persönlichen öffentlichen Schlüssel eines Entwicklers als «vorübergehende» Identität für einen CI-Worker oder Remote-Agent. Dadurch bleibt der Audit-Trail unklar. Wenn ein Authentifizierungsprotokoll meldet, dass der persönliche Schlüssel sich angemeldet hat, lässt sich nur schwer feststellen, ob der Entwickler, ein Build-Job oder eine kompromittierte Remote-Shell über Weiterleitung gehandelt hat.

Für von Agents gesteuerte HTTP- und SSH-Aktionen besteht eine weitere Möglichkeit darin, Zugangsdaten in einem lokalen Aktions-Gateway zu halten und dem Agent nur den Befehl oder das API-Ergebnis zurückzugeben. Sallyport verwendet dieses Modell unter macOS: Der Tresor hält den SSH-Schlüssel, und das Hilfsprogramm sp-ssh führt die SSH-Aktion aus, ohne dem Agent selbst die Zugangsdaten zu geben.

Die entscheidende Grenze ist praktisch, nicht nur sprachlich. Der Agent fordert eine benannte Aktion an, das Gateway verwendet die Zugangsdaten und der Agent erhält die Ausgabe. Der Agent bekommt keinen Agent-Socket, den er an einen beliebigen Remote-Prozess weitergeben kann. Dadurch werden Bestätigungen und Protokolle aussagekräftig, weil sie sich auf eine konkrete Aktion beziehen und nicht auf eine offene Fähigkeit, künftig Signaturen anzufordern.

Bestätigungsdialoge verringern das Risiko, lösen aber kein Vertrauensproblem

Manchmal benötigt eine kurze Wartungsaufgabe tatsächlich Weiterleitung, und eine eigene Identität ist noch nicht eingerichtet. Leite in diesem Fall so wenig Signierberechtigung wie möglich weiter und mache jede verbleibende Verwendung sichtbar. Das ist eine vorübergehende Maßnahme, keine dauerhafte Architektur.

Starte einen separaten Agent-Socket, statt den Agent weiterzuleiten, der deine tägliche Sammlung von Identitäten enthält. Füge nur die für die Wartung erforderliche Identität hinzu, mit kurzer Gültigkeitsdauer und Bestätigungsanforderung:

ssh-agent -a "$HOME/.ssh/maintenance-agent.sock" > "$HOME/.ssh/maintenance-agent.env"
. "$HOME/.ssh/maintenance-agent.env"
ssh-add -c -t 900 ~/.ssh/maintenance_ed25519
ssh -o ForwardAgent=yes [email protected]

ssh-add -c verlangt vor dem Signieren eine Bestätigung. -t 900 entfernt die Identität nach 15 Minuten. Lies das Handbuch ssh-add(1) deiner installierten OpenSSH-Version, da das Bestätigungsverhalten vom lokalen Agent und seiner Benutzeroberfläche abhängt.

Verwende für diese Aufgabe eine eigene Shell. Entferne die Identität nach Abschluss und beende den Agent:

ssh-add -D
ssh-agent -k

Dadurch werden spätere Anfragen über diesen temporären Socket verhindert. Bereits ausgegebene Signaturen, bereits authentifizierte Verbindungen oder Datenkopien, die ein Remote-Prozess erhalten hat, werden dadurch nicht widerrufen. Schließe die Remote-Sitzung und prüfe die Ziele, auf die diese Identität zugreifen konnte.

OpenSSH unterstützt in Versionen mit dieser Funktion außerdem Zielbeschränkungen über ssh-add -h. Sie können anhand der Hostschlüssel in known_hosts festlegen, für welche Hostpfade ein Agent signieren darf. Für kontrollierte Umgebungen lohnt sich eine Prüfung. Allerdings entstehen zusätzliche Konfigurationsabhängigkeiten, die Teams oft nicht pflegen. Eine veraltete oder unvollständige known_hosts-Datei kann eine Sicherheitsmaßnahme im ungünstigsten Moment in einen Ausfall verwandeln. Teste sie mit dem exakten Jump-Pfad und den Host-Aliasen deiner Automatisierung.

Verlasse dich nicht auf Ermüdung durch Bestätigungsdialoge als Sicherheitsgrenze. Ein kompromittierter Host kann wiederholt Signaturen anfordern und Ziele nennen, die wie normale Infrastruktur aussehen. Wenn Bediener während eines Vorfalls Anfragen schnell bestätigen, schützt diese Funktion weniger, als sie glauben. Eine eng begrenzte Identität und eine kurze Gültigkeitsdauer halten den möglichen Schaden kleiner.

Protokolle müssen Sitzungen und SSH-Aktionen unterscheiden

SSH-Authentifizierungsprotokolle zeigen, dass sich ein Schlüssel bei einem Server authentifiziert hat. Sie zeigen nur selten, warum die Signatur angefordert wurde oder ob Agent-Weiterleitung den Weg ermöglicht hat. Wenn du automatisierte Remote-Aktionen zulässt, erfasse genug Informationen, um nachzuvollziehen, wer den Agent gestartet hat, welcher Prozess eine Bestätigung erhielt, welches Ziel er kontaktierte und welche Aktion angefordert wurde.

Halte Sitzungsprotokolle von Aktionsprotokollen getrennt. Ein Sitzungsdatensatz beantwortet, welcher Agent-Prozess wann Zugriff erhielt und wann dieser endete. Ein Aktionsdatensatz beantwortet, welcher SSH-Befehl oder API-Aufruf unter diesem Zugriff ausgeführt wurde. Werden beide Informationen in einem allgemeinen Ereignisprotokoll vermischt, dauern Untersuchungen länger, weil Bediener Ursache und Wirkung aus einzelnen Fragmenten ableiten müssen.

Prüfe auf einem SSH-Server nach einem verdächtigen Weiterleitungsereignis die normalen Authentifizierungsprotokolle. Der genaue Speicherort hängt von Betriebssystem und Dienstkonfiguration ab. Häufig sind es Einträge im System-Journal und das Authentifizierungsprotokoll des SSH-Daemons. Suche nach dem Fingerabdruck des akzeptierten öffentlichen Schlüssels, dem Konto, der Quelladresse und dem Zeitpunkt. Vergleiche diese Angaben mit dem Sitzungsverlauf des ersten Remote-Hosts.

Leite aus einer IP-Adresse keine Gewissheit ab. Eine weitergeleitete Verbindung kann von einem Build-Host, einem Bastion-Host, einem NAT-Gateway oder einem privaten Overlay stammen. Der Server kann feststellen, woher die TCP-Verbindung kam, nicht aber, wer die Signaturanfrage auf dem Rechner des Entwicklers ausgelöst hat.

Manipulationssichere Datensätze helfen nur, wenn das System sie außerhalb der Kontrolle des Agents schreibt. Ein Prozess, der seinen eigenen Aktionsverlauf bearbeiten kann, kann den verdächtigen zweiten Hop löschen, bevor jemand nachsieht. Sallyport protokolliert Agent-Sitzungen und einzelne Aufrufe in einem verschlüsselten, hashverketteten Audit-Log. sp audit verify kann diese Kette offline ohne Tresorschlüssel prüfen.

Unabhängig vom verwendeten Tool solltest du die Aufzeichnung mit einer tatsächlich fehlgeschlagenen Autorisierung und einem tatsächlich erfolgreichen SSH-Befehl testen. Stelle sicher, dass Agent-Lauf, Ziel, Credential-Referenz oder Fingerabdruck, Ergebnis und Zeitpunkt genannt werden. Ein Protokoll, das nur «Tool abgeschlossen» meldet, kann eine Untersuchung zur Wiederverwendung einer Identität nicht beantworten.

Behandle eine Offenlegung als Missbrauch der Autorisierung, nicht automatisch als Diebstahl des Schlüssels

Wenn du feststellst, dass du einen Agent an einen nicht vertrauenswürdigen Host weitergeleitet hast, verhalte dich so, als könnte dieser Host deine Identität während der Sitzung verwendet haben. Warte nicht auf den Beweis, dass er einen privaten Schlüssel ausgelesen hat. Das relevante Risiko ist eine nicht autorisierte Authentifizierung. Der private Schlüssel kann dein Gerät dabei nie verlassen haben.

Stoppe zunächst die zukünftige Verwendung. Beende alle SSH-Sitzungen zu diesem Host, entferne die offengelegte Identität aus dem Agent und deaktiviere die hostbezogene Weiterleitungsregel. Wenn die Identität in einem gemeinsam genutzten Agent geladen war, führe nicht reflexartig ssh-add -D an einem Arbeitstag aus und erkläre die Angelegenheit für erledigt. Das kann legitime Sitzungen unterbrechen, während der betroffene öffentliche Schlüssel auf Servern weiterhin autorisiert ist.

Entferne oder widerrufe anschließend die Autorisierung auf den erreichbaren Zielsystemen. Bei gewöhnlichen authorized_keys-Konfigurationen entfernst du den öffentlichen Schlüssel aus Konten, in denen er nicht mehr funktionieren soll, und ersetzt ihn bei Bedarf durch einen neuen. Bei SSH-Zertifikaten widerrufst du das Zertifikat entsprechend deiner CA und deines Serverprozesses oder lässt ein kurzlebiges Zertifikat ablaufen, wenn du sicherstellen kannst, dass das Zeitfenster akzeptabel ist. Für Repository-Zugriff widerrufst oder ersetzt du das entsprechende Deploy- oder Benutzer-Credential über die üblichen Kontrollen des Dienstes.

Untersuche ein begrenztes Zeitfenster: von dem Zeitpunkt, an dem die Weiterleitung verfügbar wurde, bis die Remote-Sitzung endete oder der lokale Agent keine Anfragen mehr annahm. Prüfe die Authentifizierungsprotokolle der Ziele, vertrauenswürdige Remote-Shell-Historien, Job-Datensätze und Aktionsprotokolle. Sichere die Protokolle, bevor du den Remote-Host bereinigst, falls du eine Kompromittierung vermutest.

Behebe schließlich den Weg, der den Vorfall ermöglicht hat. Wenn ein globales ForwardAgent yes die Ursache war, reicht es nicht, nur den Eintrag des kompromittierten Hosts zu ändern. Der nächste unbekannte Host wäre weiterhin gefährdet. Wenn ein KI-Workflow einen persönlichen Socket geerbt hat, gib diesem Workflow eine ausdrückliche Verbindungsdefinition und eine eigene Workload-Identität. Die Reparatur sollte den unsicheren Weg standardmäßig unmöglich machen und nicht nur daran erinnern, ein Flag zu setzen.

Die sichere Standardeinstellung muss auch unter Zeitdruck funktionieren

Weiterleitung bleibt beliebt, weil sie im Moment Aufwand spart. Ein Entwickler braucht einen weiteren Hop, ein Build muss private Daten abrufen oder ein Agent muss vor einer Frist eine Aufgabe abschließen. Das sind echte Anforderungen. Sie rechtfertigen nicht, eine weitreichende Entwickleridentität auf jeden Rechner zu legen, der zufällig auf dem Weg liegt.

Setze global ForwardAgent no. Verwende ProxyJump für Bastion-Hosts, die ausschließlich als Transportweg dienen. Weise der Remote-Automatisierung eine Identität zu, die ihre erlaubten Aktionen beschreibt. Wenn eine vorübergehende Ausnahme unvermeidbar ist, isolierst du eine Identität, verlangst eine Bestätigung, setzt eine kurze Gültigkeitsdauer und entfernst sie nach Abschluss der Aufgabe.

Führe ssh -G für die Host-Aliase aus, die dein Team in dieser Woche verwendet. Diese kleine Prüfung erkennt den stillen Konfigurationsfehler, bevor ein Remote-Prozess einen Signierdienst erhält, den er nie haben sollte.