Zugriff auf Bastion-Hosts für KI-Coding-Agenten, richtig umgesetzt

Ein Bastion-Host kann KI-Coding-Agenten einen sichereren Weg in private Infrastrukturen geben. Das funktioniert aber nur, wenn du ihn als Teil einer Zugangsgrenze behandelst. Ein Jump-Host, der lediglich in einer SSH-Konfigurationsdatei auftaucht, ist keine Kontrolle. Der Agent kann ihn umgehen, sich Zugangsdaten ausleihen, einen Tunnel öffnen oder einen Audit-Eintrag hinterlassen, der nur beweist, dass sich irgendetwas mit dem Jump-Host verbunden hat.

Für autonome Aufgaben ist der sinnvolle Aufbau strenger: Der Agent erreicht genau einen kontrollierten Einstiegspunkt, dieser Einstiegspunkt erreicht nur bekannte Ziele, Zugangsdaten bleiben außerhalb des Agent-Kontexts, und deine Aufzeichnungen unterscheiden zwischen dem Host, den der Agent angefordert hat, und dem Host, der die Verbindung tatsächlich angenommen hat. Diese Unterscheidung klingt kleinlich, bis die erste Untersuchung eines Vorfalls beginnt. Dann entscheidet sie darüber, ob du Beweise oder nur eine beruhigende Geschichte hast.

Ein Bastion-Host ändert die Route, nicht die Berechtigungen des Agenten

Ein Zugriffskonzept mit Bastion-Host begrenzt die Netzwerkreichweite. Es reduziert aber nicht, was ein Agent nach dem Erreichen eines privilegierten Kontos tun kann. Teams verwechseln diese Aufgaben oft, weil beide mit SSH zu tun haben. Es handelt sich um getrennte Kontrollen, die auch unabhängig voneinander ausfallen sollten.

Ein Jump-Host hilft, wenn private Ziele Administrationsverkehr nur von diesem Host oder Subnetz akzeptieren. Er bietet einen zentralen Ort, an dem du ausgehende Verbindungen begrenzen, Verbindungsnachweise sammeln und den Zugriff während einer Untersuchung abschalten kannst. Außerdem müssen nicht mehr jede Workstation, jeder Build-Runner und jede Agent-Sandbox direkte Routen in sensible Netzwerke besitzen.

Er beantwortet jedoch vier Fragen nicht, die bei einem autonomen Client wichtiger sind:

• Kann der Agent das Ziel über eine andere Route direkt erreichen?
• Hat das Zielkonto mehr Berechtigungen, als die angeforderte Aufgabe benötigt?
• Kann der Agent einen Tunnel erstellen, der ihm einen ungeprüften Weg eröffnet?
• Kannst du nachträglich den endgültigen Rechner und den Remote-Befehl identifizieren?

Wenn die Antwort auf die erste Frage ja lautet, ist ProxyJump eine Komforteinstellung und keine Durchsetzung. Wenn die Antwort auf die zweite Frage ja lautet, hat der Bastion-Host lediglich den Ort verschoben, an dem ein übermäßig weitreichendes Zugangsmittel ins Netzwerk gelangt.

Ich habe Teams gesehen, die einen sorgfältig gepflegten Jump-Host aufbauten und anschließend einem CI-Subnetz breiten ausgehenden SSH-Zugriff «für die Fehlerbehebung» erlaubten. Ein Agent in diesem Subnetz braucht weder einen Exploit noch einen cleveren Trick. Er kann die endgültige Adresse direkt aufrufen. Die Architektur ist gescheitert, weil das Netzwerk den Bypass erlaubte, nicht weil SSH sich falsch verhielt.

Halte die Rollen klar. Die Agent-Umgebung sollte sich nur mit dem Einstiegshost verbinden. Der Einstiegshost sollte nur die vorgesehenen Zielnetzwerke und Ports erreichen. Der endgültige Host sollte ein Konto mit eng begrenztem Zweck autorisieren. Jede Schicht sollte Aufzeichnungen erzeugen, die eine andere Frage beantworten.

ProxyJump macht den endgültigen Befehl nicht sichtbar

Ein SSH-Jump-Host kann den Befehl, den der Agent auf dem endgültigen Host ausführt, normalerweise nicht einsehen. Das übersehen Teams, wenn sie «vollständige Befehlsprotokolle vom Bastion-Host» versprechen.

OpenSSH beschreibt ProxyJump in ssh_config(5) als Verbindung zum Jump-Host mit anschließender Weiterleitung zum endgültigen Ziel. Bei der üblichen Verwendung von OpenSSH bittet der Client den Jump-Host im Grunde darum, eine TCP-Verbindung zum Ziel herzustellen. Danach führt der Client seine durchgehende SSH-Sitzung über diesen Bytestrom. Der endgültige SSH-Transport bleibt zwischen Client und Ziel verschlüsselt.

Der Bastion-Host kann häufig wissen, dass er eine Verbindung zu 10.42.8.19:22 hergestellt hat. Er kann das auf dem Bastion-Host verwendete Konto, die Quelle, den Zeitpunkt und das Ziel einer Weiterleitungsanfrage protokollieren. Automatisch weiß er jedoch nicht, ob die verschlüsselte Sitzung später systemctl restart api, cat /etc/shadow oder eine interaktive Shell ausgeführt hat.

Dadurch entstehen drei verschiedene Beobachtungen, die oft zu einer einzigen zusammengefasst werden:

1. Das angeforderte Ziel ist das, was der Agent angegeben hat, zum Beispiel prod-api-01.
2. Das Verbindungsziel ist die Adresse und der Port, zu denen der Proxy tatsächlich eine Verbindung geöffnet hat.
3. Das Ausführungsziel ist die Identität des Servers und das Konto, das die endgültige SSH-Authentifizierung angenommen hat.

Diese Angaben können voneinander abweichen. Ein Alias kann sich nach einer DNS-Änderung anders auflösen. Ein kompromittierter oder veralteter Known-Host-Eintrag kann eine Verbindung verdächtig machen. Eine Proxy-Regel kann einen vertrauten Alias an eine unerwartete Adresse senden. Nur prod-api-01 zu protokollieren beweist nicht, welcher Server einen Befehl ausgeführt hat.

Die gleiche Trennung gilt für Befehle. Ein Gateway auf der Client-Seite kann den angeforderten Befehl vor dem Transport erfassen. Ein Wrapper auf dem Zielhost kann den Befehl protokollieren, den OpenSSH bei einer Exec-Anfrage übergibt. Der Bastion-Host kann das TCP-Ziel erfassen. Verknüpfe diese Beobachtungen anhand einer Sitzungs-ID und eines Zeitfensters. Tu nicht so, als würde eine einzelne Schicht alles sehen.

Wenn du einen einzigen Ort brauchst, der jeden Remote-Befehl prüfen und autorisieren kann, ist gewöhnliches durchgehendes SSH über einen Jump-Host das falsche Grundelement. Nutze stattdessen einen spezialisierten Remote-Ausführungsdienst, einen eingeschränkten Befehlsendpunkt oder einen Wrapper auf dem Zielhost, der nur die vorgesehene Operation akzeptiert. Diese Entscheidung kostet Flexibilität. Sie verhindert aber auch, dass du eine Sichtbarkeit behauptest, die du nicht hast.

Netzwerkregeln müssen den genehmigten Weg unvermeidbar machen

Ein kontrollierter Einstiegspunkt funktioniert nur, wenn das umgebende Netzwerk alternative Wege ausschließt. Beginne mit der Erreichbarkeit, bevor du über Genehmigungsdialoge oder Log-Formate diskutierst.

Die Laufzeitumgebung des Agenten braucht ausgehendes SSH nur zur Adresse und zum Port des Bastion-Hosts. Sie sollte keine breite Route zu Produktions-Subnetzen, öffentlichen Management-Schnittstellen oder einem zweiten Jump-Host besitzen, der nie Teil des Konzepts war. Auch DNS ist hier wichtig. Wenn der Agent rohe Zieladressen auflösen und verbinden kann, schützt dich eine Konvention für freundliche Hostnamen nicht.

Der Bastion-Host braucht eine kurze Liste erlaubter ausgehender Ziele. Wenn er Hosts auf TCP-Port 22 in zwei privaten Bereichen verwaltet, erlaube diese Bereiche und diesen Port. Gib ihm keinen beliebigen ausgehenden Zugriff und nenne den Host dann Bastion-Host. Ein Einstiegshost, der jeden Dienst, jede Datenbank und jeden öffentlichen Endpunkt erreichen kann, wird zu einem allgemeinen Relay, sobald das Agent-Konto missbraucht wird.

Die endgültigen Ziele sollten SSH-Administration nur über den Weg des Bastion-Hosts akzeptieren. Cloud-Sicherheitsgruppen, Host-Firewalls und Netzwerk-ACLs können jeweils helfen. Nutze mehrere davon nur, wenn ihre Zuständigkeiten klar bleiben. Eine Regel, die niemand pflegt, ist keine Verteidigung.

Teste die Route mit Ablehnungsfällen, nicht nur mit dem erfolgreichen Befehl. Führe diese Prüfungen vom selben Benutzer, Container oder derselben VM aus, in der der Agent läuft:

nc -vz bastion.internal.example 22
nc -vz 10.42.8.19 22
ssh -o ConnectTimeout=5 prod-api-01 true

Die erste Verbindung sollte funktionieren. Die direkte Verbindung zum endgültigen Host sollte scheitern. Der SSH-Befehl sollte nur funktionieren, weil seine konfigurierte Route den Bastion-Host verwendet. Wenn nc fehlt, nutze den in deiner Umgebung üblichen Befehl für einen TCP-Test. Entscheidend ist, den Netzwerkpfad zu prüfen, ohne dass die SSH-Konfiguration eine direkte Route versteckt.

Wiederhole den Test nach Firewall-Änderungen, neuen Subnetzen und Änderungen am Agent-Runner. Das ist ein kleiner Test mit ungewöhnlich großer Wirkung. Er findet den häufigen Fall, bei dem die SSH-Konfiguration korrekt aussieht, während das Netzwerk weiterhin eine direkte Verbindung erlaubt.

Der Agent braucht eine Identität, die du widerrufen kannst

Gib einem Agenten keinen gemeinsam genutzten Administratorschlüssel und hoffe, dass der Bastion-Host das akzeptabel macht. Ein kopierter privater Schlüssel ist eine Autorisierungsentscheidung mit sehr langer Wirkung.

Gib jedem Agent-Prozess oder Lauf eine Identität, die du zuordnen und widerrufen kannst. Möglich sind ein kurzlebiges SSH-Zertifikat, ein für eine begrenzte Aufgabe registrierter temporärer Schlüssel oder ein Zugangsmittel, das in einem Aktions-Gateway liegt, das SSH im Auftrag des Agenten ausführt. Die richtige Wahl hängt von deiner Umgebung ab. Der Agent sollte aber kein wiederverwendbares Geheimnis in sein Protokoll, seinen Arbeitsbereich, den Shell-Verlauf oder die Tool-Ausgabe schreiben.

SSH-Zertifikate helfen, wenn du bereits eine SSH-Zertifizierungsstelle betreibst. Ein Zertifikat kann eine kurze Gültigkeitsdauer, einen Principal für das Zielkonto und kritische Optionen wie Einschränkungen der Quelladresse enthalten. Das Ziel kann der CA vertrauen, statt eine wachsende Liste einzelner öffentlicher Schlüssel zu pflegen. Dadurch lassen sich Ausstellung und Ablauf leichter prüfen.

Zertifikate machen ein weitreichendes Konto nicht automatisch eingeschränkt. Ein Zertifikat für root bleibt bis zu seinem Ablauf ein Root-Zugang. Zertifikate beweisen auch nicht die Absicht eines Befehls. Behandle sie als Mechanismus für Ausstellung und Gültigkeitsdauer.

Ein Gateway verändert das Gefährdungsmuster deutlicher. Sallyport kann SSH über seinen Helfer sp-ssh ausführen, während der SSH-Schlüssel in seinem verschlüsselten Tresor bleibt und den Agent-Prozess nicht erreicht. Das schützt den privaten Schlüssel vor dem Agent-Protokoll. Teams sollten trotzdem prüfen, wie der vorgesehene Jump-Weg, die Zielidentität und die Befehlsnachweise aufgezeichnet werden.

Verknüpfe die Genehmigung mit einem identifizierbaren Prozess, nicht mit dem Satz, den der Agent in ein Chatfenster geschrieben hat. Ein Prozess kann signiert, zu einem Zeitpunkt gestartet, einem lokalen Benutzer zugeordnet und als laufende Sitzung widerrufen werden. Eine Erklärung in natürlicher Sprache liefert nützlichen Kontext, ist aber keine Zugangsgrenze.

Vermeide ein Zugangsmittel, das von allen automatisierten Aufgaben gemeinsam verwendet wird. Wenn ein Log auf dem Zielhost deploy meldet, brauchst du einen zweiten Eintrag, der den aufrufenden Agent-Lauf identifiziert. Wenn jeder Lauf denselben Schlüssel und dasselbe Konto nutzt, wird die Untersuchung eines Vorfalls zur Archäologie.

Erfasse eine Ausführungsbehauptung, eine Routeninformation und ein Ergebnis

Ein SSH-Audit-Eintrag für einen Agenten sollte genau angeben, was jedes Feld bedeutet. So verhinderst du, dass das Auditsystem Aussagen macht, die es nicht belegen kann.

Zum Zeitpunkt der Aktionsanfrage solltest du die Identität des Agent-Laufs, den angeforderten Host-Alias, das angeforderte Remote-Konto, den Befehlstext oder eine strukturierte Operation sowie die Anforderung eines TTY oder einer Weiterleitung erfassen. Das ist die Ausführungsbehauptung. Sie zeigt, was der Aufrufer zu tun versucht hat.

An der Routengrenze solltest du die Identität des Einstiegshosts, die aufgelöste Zieladresse, den Zielport und das Ergebnis der Verbindung erfassen. Das ist die Routeninformation. Wenn der Proxy eine Verbindung öffnet, kann er angeben, wohin er sie geöffnet hat. Aus verschlüsselten Bytes kann er den endgültigen Befehl nicht wahrheitsgemäß ableiten.

Auf dem endgültigen Host solltest du die stabile Identität des Zielhosts, das authentifizierte Konto, den Authentifizierungs-Fingerabdruck oder die Seriennummer des Zertifikats, den Befehl bei einer vom Server empfangenen Exec-Anfrage, den Exit-Status und relevante lokale Dienstprotokolle erfassen. Das ist der Ausführungsnachweis. Der endgültige Host ist der einzige normale SSH-Endpunkt, der den Remote-Befehl sehen kann, ohne das durchgehende Design von SSH aufzubrechen.

Nutze eine Ereignisstruktur, die fehlende Nachweise sichtbar macht:

{
  "run_id": "run_7c31",
  "requested": {
    "host": "prod-api-01",
    "user": "deploy",
    "command": "sudo systemctl restart api",
    "tty": false
  },
  "route": {
    "bastion": "bastion.internal.example",
    "destination_ip": "10.42.8.19",
    "destination_port": 22
  },
  "final_host": {
    "host_fingerprint": "SHA256:example",
    "authenticated_user": "deploy",
    "command_observed": true,
    "exit_status": 0
  }
}

Das Beispiel trennt absichtlich requested.command von einer Beobachtung auf dem endgültigen Host. Wenn die Sitzung interaktiv war, setze command_observed auf false und erläutere den Grund. Ein leeres Feld ohne Erklärung verleitet dazu, anzunehmen, dass das Tool den Befehl erfasst hat.

Für die normale Befehlsausführung dokumentiert sshd_config(5) ForceCommand, das für ein passendes Konto oder einen passenden Match-Block einen Befehl erzwingt. Ein Wrapper auf dem Zielhost kann SSH_ORIGINAL_COMMAND bei einer Exec-Anfrage lesen, eine erlaubte Operation prüfen und vor dem Start des genehmigten Programms einen Audit-Eintrag schreiben. Er braucht eine sorgfältige Behandlung der Shell. Übergib keine nicht vertrauenswürdige Befehlszeichenkette an eval und gehe nicht davon aus, dass SSH_ORIGINAL_COMMAND bei einer interaktiven Shell vorhanden ist.

Hash-Verkettung und eine Nur-Anhängen-Speicherung helfen dabei, spätere Änderungen an Audit-Ereignissen zu erkennen. Sie beheben keine schwachen Ereignisinhalte. Ein perfekt erhaltenes Protokoll, das nur «SSH verbunden» sagt, bleibt ein schwacher Nachweis.

Die SSH-Konfiguration überprüfbar machen

Behalte Host-Aliase für Menschen bei, aber prüfe, was OpenSSH tatsächlich tun wird, bevor du eine Konfiguration an einen Agenten übergibst. ssh -G gibt die effektive Client-Konfiguration aus, nachdem OpenSSH passende Host-Einträge verarbeitet hat.

Dieses Beispiel leitet ein benanntes Ziel über einen benannten Bastion-Host und deaktiviert Optionen, die Teams häufig überraschen:

Host agent-bastion
    HostName bastion.internal.example
    User agent-gateway
    IdentityFile ~/.ssh/agent_gateway
    IdentitiesOnly yes

Host prod-api-01
    HostName 10.42.8.19
    User deploy
    ProxyJump agent-bastion
    StrictHostKeyChecking yes
    UserKnownHostsFile ~/.ssh/agent_known_hosts
    ForwardAgent no
    RequestTTY no

Prüfe anschließend die aufgelösten Einstellungen:

ssh -G prod-api-01 | grep -E '^(hostname|user|proxyjump|forwardagent|requesttty) '

Die Ausgabe sollte dieselbe Struktur haben wie diese:

user deploy
hostname 10.42.8.19
requesttty no
forwardagent no
proxyjump agent-bastion

Das zeigt, wie sich der Client verhalten will. Es beweist nicht, dass das Netzwerk direkten SSH-Zugriff blockiert, der Zielhost den erwarteten Hostschlüssel präsentiert oder der Bastion-Host seinen ausgehenden Datenverkehr beschränkt. Prüfe diese Punkte unabhängig voneinander.

Erlaube dem Agenten nicht, beliebige ssh-Optionen frei anzugeben. Ein Agent kann die Konfiguration mit Befehlszeilenoptionen überschreiben, eine rohe IP-Adresse angeben, ProxyJump ersetzen oder Weiterleitungsoptionen hinzufügen, wenn die Ausführungsschicht einfach eine Shell-Zeichenkette durchreicht. Übergib Ziel, Konto und erlaubte SSH-Optionen möglichst als strukturierte Aktionsparameter. Wenn du einen rohen Befehl akzeptierst, behandle ihn wie Code und misstraue ihm genauso wie einem Shell-Skript aus einer nicht vertrauenswürdigen Quelle.

Die Prüfung von Hostschlüsseln verdient besondere Aufmerksamkeit, weil Agenten automatisch wiederholen und einen Fehler oft als Hindernis für die Aufgabe behandeln. Lade vertrauenswürdige Host-Fingerprints über einen kontrollierten Prozess vor. Lass die strikte Prüfung aktiviert. Bringe dem Agenten nicht bei, Known-Host-Einträge zu löschen oder geänderte Schlüssel zu akzeptieren, damit ein Deployment weitergeht. Eine Änderung des Hostschlüssels muss ein Operator auf ihre Ursache prüfen.

Weiterleitungen und Shells schaffen Wege an deiner Prüfung vorbei

Deaktiviere Weiterleitungen und interaktive Shells für autonome Agenten, sofern eine konkrete Aufgabe sie nicht benötigt. Beide Funktionen machen aus einem begrenzten Remote-Befehl einen breiteren Zugangskanal.

Lokale Weiterleitungen ermöglichen es einem Client, einen lokalen Port zu öffnen, der über SSH einen internen Dienst erreicht. Eine entfernte Weiterleitung ermöglicht einem entfernten Endpunkt, einen Weg zurück zur Client-Seite bereitzustellen. Eine dynamische Weiterleitung erstellt einen SOCKS-Proxy. Agent-Weiterleitung macht Zugangsdaten auf einem anderen Host verfügbar. Jede dieser Funktionen kann für einen menschlichen Administrator legitim sein. Jede schwächt aber auch die Aussage, dass der Bastion-Host der einzige kontrollierte Weg ist.

OpenSSH bietet Serverbeschränkungen, die auf dem endgültigen Ziel oder dem Bastion-Konto gelten sollten, nicht nur in der Client-Konfiguration des Agenten. sshd_config(5) dokumentiert DisableForwarding, und authorized_keys unterstützt Optionen wie no-port-forwarding, no-agent-forwarding, no-X11-forwarding und no-pty. Nutze die Kontrollen, die deine OpenSSH-Version unterstützt, und überprüfe sie anschließend mit einem echten Verbindungsversuch.

Ein eingeschränktes Konto könnte einen autorisierten Schlüsseleintrag wie diesen verwenden:

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-run

Diese Zeile beschränkt die Funktionen für diesen öffentlichen Schlüssel. Sie beschränkt jedoch nicht die Befehle, die das Konto ausführen kann. Kombiniere sie mit einem eingeschränkten Konto, einem ForceCommand-Wrapper oder einer dienstspezifischen Schnittstelle, wenn der Befehlsumfang wichtig ist.

Für interaktive Shells gilt eine klare Regel: Gib einem autonomen Agenten standardmäßig keine. Eine Shell akzeptiert eine Folge von Befehlen, Pipes, Umleitungen, Hintergrundprozessen und kopierten Zugangsdaten. Das Befehlsfeld der ursprünglichen Aktionsanfrage beschreibt dann nicht die vollständige Sitzung. Ein erzwungener Wrapper kann eine Shell blockieren, aber teste ihn, weil sich das Shell-Verhalten je nach Kontokonfiguration und SSH-Subsystem-Anfragen ändert.

Manche Wartungsaufgaben benötigen tatsächlich einen Tunnel oder eine Shell. Behandle sie als ausdrückliche Ausnahmewege mit benannter Operator-Genehmigung und kurzer Gültigkeitsdauer. Eine Ausnahme in einem allgemeinen Agent-Zugangsmittel zu verstecken, ist der Weg von temporärem Zugriff zu dauerhaftem Zugriff.

Beschränkungen auf dem Ziel sind besser als Filter für Befehlszeichenketten

Eine einfache Allowlist von Präfixen für Shell-Befehle lässt sich leicht umgehen und schwer pflegen. Sie ist beliebt, weil sie präzise wirkt: systemctl restart api erlauben, alles andere ablehnen. Die Shell-Syntax macht diese Sicherheit jedoch brüchig.

Nehmen wir einen Filter, der Text akzeptiert, der mit systemctl restart api beginnt. Ein Aufrufer kann einen Shell-Operator anhängen, einen anderen Programmpfad verwenden, über eine Umgebungsvariable Verhalten auslösen oder einen Wrapper ausnutzen, der die Zeichenkette anders interpretiert. Selbst ein sorgfältiger Parser kann nicht jede Wirkung eines Befehls kennen, der ein weiteres Programm aufruft.

Nutze strukturierte Operationen, wenn die Aufgabe eine stabile Form hat. Ein Deployment-Runner kann einen Anwendungsnamen und eine Release-ID akzeptieren. Ein Wartungsendpunkt kann einen Dienstnamen aus einer festen Liste annehmen. Ein eingeschränkter Wrapper kann einen kleinen Operationsnamen auf ein festes argv-Array abbilden. Vermeide in allen Fällen eine Shell.

Wenn du freie Befehle unterstützen musst, benenne klar, was du erlaubst: Remote-Shell-Berechtigung für dieses Konto. Protokolliere sie, begrenze die Gültigkeitsdauer des Zugangsmittels, beschränke die Zielumgebung und verlange eine separate Genehmigungsstufe. Verkaufe einen Zeichenkettenfilter nicht als Befehlsautorisierung.

Das Zielkonto sollte außerdem eine Berechtigungsgrenze des Betriebssystems haben. Ein deploy-Konto, das uneingeschränktes sudo ausführen kann, ist praktisch ein Administratorkonto mit zusätzlicher Schreibarbeit. Gib ihm nur die Dienstaktionen, Dateien und Verzeichnisse, die seine Automatisierung benötigt. Prüfe seine sudo-Regeln wie Code, einschließlich jedes Befehls- und Argumentmusters.

Der praktische Test lautet: Kann ein Agent, der einen Dienst neu starten soll, Produktionsgeheimnisse lesen, einen Rückwärtstunnel erstellen, SSH-Berechtigungen ändern oder den Audit-Sammler manipulieren? Wenn ja, ist der Umfang des Kontos falsch, selbst wenn jede Verbindung den richtigen Bastion-Host verwendet.

Die Reaktion auf Vorfälle beginnt mit dem Stoppen der aktiven Route

Wenn sich ein Agent verdächtig verhält, widerrufe seinen aktiven Zugriff, bevor du seine Absicht rekonstruierst. Beende seine aktive Sitzung an der Aktionsgrenze, sofern du dort eine Kontrolle hast, blockiere die Quelle am Bastion-Host und verhindere, dass sich das zugehörige Zugangsmittel erneut authentifiziert. Sichere die Logs, bevor jemand Dateien rotiert oder den Host mit den Beweisen neu startet.

Erstelle anschließend aus den getrennten Aufzeichnungen eine Zeitleiste. Beginne mit der angeforderten Aktion des Agenten. Ordne ihr das Verbindungsziel und den Zeitpunkt am Bastion-Host zu. Ordne diese wiederum der Authentifizierung und den Befehlsnachweisen auf dem endgültigen Host zu. Prüfe, ob ein TTY, eine Weiterleitungsanfrage oder ein alternatives Ziel auftauchte. Eine Abweichung ist nicht automatisch bösartig. Sie zeigt dir aber, welche Kontrolle untersucht werden muss.

Reagiere nicht, indem du dauerhaft mehr Zugriff gewährst, «damit der Agent das Problem reparieren kann». Das ist eine häufige Panikreaktion. Wenn sich der Agent bereits außerhalb der Erwartungen verhalten hat, beseitigt eine Erweiterung seines Kontos oder eine direkte Route die benötigten Beweise und erzeugt einen weiteren Vorfall.

Führe eine kleine Übung durch, bevor du sie in der Produktion brauchst. Widerrufe einen Testagenten während eines harmlosen SSH-Befehls, bestätige, dass neue Anfragen scheitern, und prüfe, ob deine Aufzeichnungen den angeforderten Host, die tatsächliche Route, die Zielidentität und das Ergebnis anzeigen. Wenn dafür ein Gruppenchat nötig ist, um herauszufinden, was passiert ist, bleibt dein Zugriffskonzept zu unklar.

Ein Bastion-Host verdient seinen Platz, wenn er eine Route durchsetzt, einen schnellen Widerruf unterstützt und eine präzise Information zur Audit-Spur beiträgt. Konfiguriere zuerst die Route, halte Zugangsdaten aus dem Agenten heraus und erfasse Nachweise auf dem endgültigen Host, wo die endgültigen Befehle sichtbar sind. Alles andere ist SSH-Komfort mit einem sicherheitsbewussten Namen.