Ist die Sicherheit von SSH ProxyCommand schwächer, als sie scheint?

SSH ProxyCommand ist lokale Codeausführung, die stattfindet, bevor der Remote-Befehl läuft, den Sie eigentlich ausführen wollten. Das klingt offensichtlich, sobald man es ausspricht. Trotzdem behandeln Reviews es oft als Transportdetail: Der Agent fordert ssh host uptime an, der Prüfer kontrolliert Host und Remote-Befehl, und der Client startet unbemerkt einen lokalen Shell-Befehl, den niemand in die Freigabeentscheidung einbezogen hat.

Diese Lücke zählt umso mehr, wenn ein autonomer Programmieragent SSH aufrufen kann. Das Remote-Ziel kann eng begrenzt sein, während die lokale SSH-Konfiguration Aliasnamen, Includes, bedingte Regeln, einen Proxy-Helfer und eine über Jahre gewachsene Kette von Jump Hosts enthält. Eine sichere Prüfung beginnt mit der clientseitigen Aktion, die SSH ausführt, und arbeitet sich dann zum Netzwerk vor.

ProxyCommand läuft, bevor die Remote-Sitzung besteht

ProxyCommand weist den SSH-Client an, einen lokalen Befehl zu starten und dessen Standardeingabe und Standardausgabe als Transport zum SSH-Server zu verwenden. Der Befehl läuft nicht am Ziel. Er läuft auf dem Rechner, der ssh gestartet hat, unter dem dortigen Konto und bevor SSH den vorgesehenen Server authentifizieren kann.

Ein typischer Eintrag wirkt harmlos:

Host build-private
    HostName build.internal.example
    ProxyCommand /usr/local/bin/connect-private %h %p

Wenn jemand ssh build-private ausführt, erweitert SSH %h und %p und startet dann /usr/local/bin/connect-private build.internal.example 22. Der Helfer kann einen Socket öffnen, einen weiteren Client aufrufen, eine Token-Datei lesen, eine Bibliothek laden, Umgebungsvariablen abfragen oder ein Shell-Skript ausführen. Ab diesem Punkt sieht der SSH-Client nur noch einen Bytestrom. Ihre Freigabeaufforderung kann eine SSH-Verbindung beschreiben, obwohl die erste wesentliche Aktion der Start eines lokalen Programms war.

Das OpenSSH-Handbuch zu ssh_config beschreibt die Grenze klar: ProxyCommand legt den Befehl fest, mit dem die Verbindung zum Server hergestellt wird, und warnt davor, dass der Befehl über die Shell des Benutzers ausgeführt wird. Dieser letzte Zusatz verändert die Prüfung. Eine Befehlszeile ist kein Argument-Array. Shell-Parsing, Erweiterungen, Umleitungen, Befehlssubstitutionen und die Startumgebung der Shell gehören zur Aktion.

Winken Sie das nicht ab, nur weil der Helfer in einem Dotfiles-Repository liegt. Eine vor sechs Monaten geprüfte Konfiguration kann ein über PATH gefundenes Programm aufrufen, eine Datei in einem beschreibbaren Verzeichnis einbinden oder von einem Alias abhängen, der inzwischen anders aufgelöst wird. Ziel der Prüfung ist der tatsächlich aufgelöste Ausführungspfad auf dem Rechner, der ihn ausführen wird.

Ein Host-Alias kann weit mehr als einen Host auswählen

Die SSH-Konfiguration ist ein Abgleichsystem, kein einfaches Wörterbuch. Ein kurzer Alias kann Einstellungen aus der Systemkonfiguration, der Benutzerkonfiguration, eingebundenen Fragmenten, Platzhalter-Hosts, Kanonisierung und bedingten Blöcken auslösen. Der endgültige Befehl kann aus einer Datei stammen, die niemand mit dem Alias verbindet.

Beginnen Sie damit, alle Konfigurationen aufzulisten, die SSH liest. Bei einem gängigen OpenSSH-Client gehören dazu /etc/ssh/ssh_config, Dateien, die über Include erreicht werden, und ~/.ssh/config. Paketierung der Distribution und Befehlszeilenoptionen können diese Liste verändern, prüfen Sie also auch den Aufruf. Wer -F /some/file übergibt, hat die gesamte Prüfoberfläche verändert.

Verwenden Sie ssh -G, um die aufgelöste Konfiguration für ein konkretes Ziel auszugeben. Für einen kontrollierten Testalias ist dies ein nützliches Artefakt:

ssh -G build-private | grep -E '^(hostname|user|port|proxycommand|proxyjump|identityfile) '

Die Ausgabe sieht etwa so aus:

hostname build.internal.example
user deploy
port 22
proxycommand /usr/local/bin/connect-private %h %p
identityfile ~/.ssh/id_deploy

ssh -G zeigt, was SSH ausgewählt hat. Damit fallen erstaunlich viele Fehler auf: ein weit gefasster Host *-Eintrag, ein altes Include oder ein Alias, der einem anderen Konto als erwartet zugeordnet ist. Es beweist nicht, dass der Helfer sicher ist. Außerdem zeigt es möglicherweise nicht jede Bedingung so, dass ein Prüfer nachvollziehen kann, wie sie zustande kam. Verfolgen Sie daher jede relevante Direktive bis zu ihrer Quelldatei zurück.

Behandeln Sie Host-Eingaben nur dann als Daten, wenn die Konfiguration sie als Daten behandelt. Wenn ein Agent beliebige Aliase übermitteln kann, kann er jeden passenden Host-Abschnitt auswählen, den das lokale Konto lesen darf. Kann er beliebige -o-Optionen oder einen Konfigurationspfad übermitteln, kann er die Alias-Prüfung oft vollständig umgehen. Ein Wrapper, der einen frei formulierten SSH-Befehl akzeptiert, ist keine sinnvolle Grenze.

Eine bessere Schnittstelle akzeptiert eine Zielkennung aus einer kleinen Allowlist und ordnet ihr ein festes Konto, einen festen Hostnamen, Port und Verbindungsmethode zu. Die Kennung kann production-readonly sein. Die zugrunde liegenden SSH-Argumente sollten nicht aus einer vom Agenten erzeugten Zeichenfolge stammen.

Shell-Erweiterungen machen die Konfiguration zu einer Eingabegrenze

Weil SSH ProxyCommand über eine Shell übergibt, schaffen Anführungszeichen in der Konfiguration nicht dieselbe Sicherheit wie strukturierte Prozessargumente. Die Shell-Syntax bleibt erhalten, bis die Shell sie verarbeitet. Dazu gehören Leerzeichen, Glob-Zeichen, Variablenreferenzen, Umleitungen und Befehlssubstitutionen, wenn sie im Befehlstext erscheinen.

Riskant wird es, wenn ein Helfer aus den erhaltenen Werten einen eigenen Shell-Befehl zusammensetzt. Betrachten Sie diese Konfiguration:

Host *
    ProxyCommand sh -c 'relay --target %h --port %p --token "$RELAY_TOKEN"'

Dazu gibt es mehrere getrennte Fragen. Entspricht jeder mögliche aufgelöste Hostname nur der erwarteten Hostname-Syntax? Interpretiert relay --target als einen einzelnen Wert? Kann eine vom Benutzer kontrollierte Umgebung RELAY_TOKEN setzen oder den Suchpfad verändern? Erhält die äußere Shell eine Befehlszeichenfolge mit Zeichen, die ihre Bedeutung verändern, bevor relay startet? Dass der Hostname von SSH kam, beantwortet diese Fragen nicht.

Prozent-Tokens sind kein sicheres Templating-System. OpenSSH erweitert Tokens wie %h, %p, %r und %n in vielen Optionen. %n ist das ursprüngliche Host-Argument, während %h der Hostname ist, den SSH nach der Verarbeitung der Konfiguration verwendet. Dieser Unterschied wird leicht übersehen. Ein Proxy-Befehl mit %n kann einen lesbaren Alias oder beliebigen angeforderten Text erhalten, wo der Autor einen kanonischen DNS-Namen erwartet hat. Ein Befehl mit %h kann immer noch einen Wert sehen, der durch HostName oder Kanonisierung verändert wurde.

Die Lösung ist meist weniger raffiniert als die ursprüngliche Einrichtung. Verwenden Sie einen kleinen, dedizierten Helfer mit festem ausführbaren Pfad, geben Sie ihm eine eingeschränkte Syntax und lassen Sie ihn alles außerhalb dieser Syntax ablehnen. Der Helfer sollte Verbindungs-APIs oder einen Prozessstarter mit Argument-Array aufrufen, statt eine weitere Shell-Zeile zusammenzusetzen. Wenn ein Shell-Skript unvermeidbar ist, validieren Sie Eingaben vor der Einfügung, setzen Sie jede Erweiterung für diese Shell korrekt in Anführungszeichen und halten Sie die akzeptierte Menge so eng, dass ein Auditor sie testen kann.

Ersetzen Sie Parsing nicht durch eval. Teams greifen danach, weil ein konfigurationsgesteuerter Wrapper damit flexibel wirkt. Ein einziges übersehenes Anführungszeichen macht daraus jedoch einen Fehler bei der lokalen Ausführung. Flexibilität gehört in ein geprüftes Konfigurationsformat, nicht in eine Shell, die Text erneut parst.

ProxyJump entfernt eine Shell, aber nicht das Vertrauensproblem

ProxyJump, oft als -J oder ProxyJump geschrieben, weist SSH an, das Ziel über einen oder mehrere SSH-Jump-Hosts zu erreichen. Für gewöhnliches Bastion-Routing sollten Sie es einem handgeschriebenen ProxyCommand vorziehen, der lediglich einen weiteren ssh -W-Befehl startet. Es beschreibt die beabsichtigte Topologie und verlagert sie nicht in einen benutzerdefinierten Shell-Befehl.

Zum Beispiel:

Host build-private
    HostName build.internal.example
    User deploy
    ProxyJump bastion-admin

Host bastion-admin
    HostName bastion.example
    User relay

Das ist leichter zu prüfen als eine Zeichenfolge mit verschachtelten Anführungszeichen. Es braucht dennoch eine sorgfältige Prüfung. Der Client authentifiziert sich am Jump Host, der Jump Host ist Teil der Route, und sein Name, Konto, Hostschlüssel, MFA-Anforderungen, Weiterleitungsregeln und seine Netzwerkerreichbarkeit beeinflussen die Aktion. Ein kompromittierter oder falsch konfigurierter Jump Host kann Verkehrsmuster offenlegen und einen Verbindungsversuch umleiten. Die Überprüfung des Hostschlüssels bleibt an jedem SSH-Sprung zwingend.

OpenSSH erlaubt beide Einstellungen, doch ProxyCommand hat Vorrang vor ProxyJump, wenn beide gelten. Das ist eine unangenehme Konfigurationsüberraschung. Ein Prüfer kann in einem hostspezifischen Block ein sauberes ProxyJump sehen, während eine weit gefasste frühere oder spätere passende Regel einen Proxy-Befehl liefert. Prüfen Sie das wirksame Ergebnis mit ssh -G, statt es aus einem einzelnen Abschnitt abzuleiten.

Mehrere Jump Hosts brauchen ebenfalls einen ausdrücklichen Grund. Behandeln Sie eine Kette nicht automatisch als zusätzliche Sicherheit. Jeder zusätzliche Host bedeutet eine weitere Nutzung von Zugangsdaten, Entscheidung über einen Hostschlüssel und Stelle für Audits. Verwenden Sie eine Kette nur, wenn der Netzwerkpfad sie verlangt, und dokumentieren Sie, welches Konto an jedem Sprung erwartet wird.

Include und Match exec können bei der Auswahl lokale Logik ausführen

Include macht SSH-Konfigurationen zusammensetzbar. Das ist nützlich, bis ein Repository, ein Konfigurationsmanagement-Werkzeug oder ein Installer ein Fragment in einem Verzeichnis ablegt, das breit gematcht wird. OpenSSH erweitert Glob-Muster in Include. Eine unerwartete Datei kann daher die Einstellungen eines Hosts verändern, ohne die Hauptkonfiguration anzutasten. Prüfen Sie Eigentümer und Schreibrechte eingebundener Verzeichnisse, nicht nur ihren aktuellen Inhalt.

Match fügt Bedingungen hinzu. Bedingungen wie Match host, user, localnetwork und verwandte Kriterien ändern, welche Optionen gelten. Match exec verdient eine deutlichere Warnung: SSH führt den angegebenen lokalen Befehl aus und verwendet seinen Exit-Status, um zu entscheiden, ob der Block passt. Schon das Lesen der Konfiguration kann somit ein lokales Programm starten.

Dieses Beispiel macht die Grenze sichtbar:

Match exec "/usr/local/bin/on-corporate-network"
    ProxyJump corp-bastion

Die Bedingung kann sinnvoll sein, wenn der Helfer ein festes, root-eigenes Programm mit einem einfachen Ergebnis ist. Sie wird fragil, wenn er eine Shell aufruft, eine beschreibbare Projektdatei liest, einen Netzwerkdienst kontaktiert oder von PATH abhängt. Testen Sie unbekannte Match exec-Regeln nicht auf einer Arbeitsstation mit aktiven Zugangsdaten, nur weil Sie ssh -G ausführen wollten. Prüfen Sie zuerst den Befehl und verwenden Sie bei Bedarf ein isoliertes Konto oder einen isolierten Rechner.

Das OpenSSH-Handbuch dokumentiert auch Token-Erweiterungen in Matching- und befehlsbezogenen Optionen. Eine Match exec-Bedingung kann daher vom angeforderten Host- oder Benutzertext abhängen. Halten Sie vom Agenten ausgewählte Werte aus diesen Bedingungen heraus. Wenn die Bedingung Kontextdaten braucht, leiten Sie sie aus einer vertrauenswürdigen lokalen Zustandsdatei mit strengen Eigentumsrechten ab, nicht aus einer Zeichenfolge, die eine Agentengrenze überschritten hat.

Der Vorfall beginnt meist mit einem Komfort-Helfer

Ein realistischer Fehler braucht keine offensichtlich bösartige Konfiguration. Stellen Sie sich vor, ein Entwickler hat vor Jahren Folgendes hinzugefügt, um ein privates Testnetz zu erreichen:

Host test-*
    ProxyCommand connect-testnet %h %p

connect-testnet wurde einst von einem Bootstrap-Skript in einem persönlichen bin-Verzeichnis installiert. Das Skript ruft einen Unternehmens-VPN-Client auf und startet dann einen Relay-Befehl, der über PATH gefunden wird. Später läuft ein Build-Agent unter dem Konto des Entwicklers. Er kann ssh test-cache anfordern. Erwartet wird ein schreibgeschützter Befehl auf einer Testmaschine.

Zuerst trifft SSH auf test-*. Danach startet die lokale Shell connect-testnet. Anschließend startet das Skript den VPN-Client und die ausführbare Datei, die aktuell bei der PATH-Suche gewinnt. Erst nach diesen lokalen Schritten beginnt SSH sein Protokoll mit dem benannten Host. Ein Audit, das nur den Remote-Befehl aufzeichnet, verliert genau das Verhalten, das den Zustand des lokalen Rechners und die Netzwerkroute verändert hat.

Der Fehler besteht nicht darin, dass Shell-Skripte verboten wären. Der Fehler besteht darin, eine lokale Komfortkette zu behandeln, als wäre sie Teil des Remote-Dienstes. Die Fähigkeit des Agenten, test-cache auszuwählen, hat lokalen Code ausgewählt. Ein böswilliger Agent könnte nach Aliasnamen suchen, die auf breitere Muster passen. Ein gewöhnlicher Agent kann dasselbe Problem auslösen, indem er einen Namen errät, der zufällig existiert.

Beheben Sie den tatsächlichen Pfad. Ersetzen Sie das Platzhaltermuster, wo möglich, durch benannte Ziele. Legen Sie den Relay-Helfer unter einem absoluten Pfad ab. Entfernen Sie PATH-Suchen darin. Der Helfer sollte nur die erwarteten Host- und Portwerte akzeptieren. Verlagern Sie die Verwaltung der VPN-Verbindung aus einem Proxy-Befehl pro Anfrage, wenn sie nicht bei jeder SSH-Aktion laufen muss. Testen Sie anschließend die endgültige Konfiguration mit dem Konto und in der Umgebung, die der Agent verwenden wird.

Die Verbindungsmethode freigeben, nicht nur das Ziel

Ein Freigabeprozess muss genug Informationen zeigen, damit eine Person die Aktion erkennen kann. ssh deploy@build-private ist unvollständiger Kontext, wenn der Alias einen Proxy-Helfer startet oder über eine Bastion geroutet wird. Der Prüfer braucht aufgelöstes Ziel, Konto, Port, Proxy-Methode und Sprungpfad. Andernfalls gibt er ein Etikett frei und hofft, dass die lokale Konfiguration noch dieselbe Bedeutung wie letzte Woche hat.

Trennen Sie drei Entscheidungen, die Teams oft vermischen. Erstens: Darf dieser Agentenprozess überhaupt eine SSH-Aktion anfordern? Zweitens: Darf er diese konkrete SSH-Identität verwenden? Drittens: Darf dieses Ziel diese bestimmte lokale Verbindungsmethode nutzen? Ein Ja zu den ersten beiden beantwortet die dritte Frage nicht automatisch. Der Proxy-Helfer kann eine andere Vertrauenszone erreichen oder lokale Nebenwirkungen auslösen, die eine direkte Verbindung nicht hätte.

Sallyport hält SSH-Zugangsdaten vom Agenten fern und verwendet für SSH-Aktionen den integrierten Helfer sp-ssh. Das macht eine lokale SSH-Konfiguration jedoch nicht zu einer sicheren Richtlinienoberfläche. Halten Sie die Ziel-Schnittstelle des Agenten eng und prüfen Sie jede Client-Konfiguration oder jeden Helferprozess, der beteiligt ist, bevor die Aktion mit Zugangsdaten beginnt.

Für sensible Pfade verlangen Sie für die SSH-Identität eine Freigabe bei jeder Nutzung und nehmen Sie Ziel und Route in die Freigabebeschreibung auf. Das deckt einen geänderten Alias, eine unerwartete Bastion oder einen Nutzungsversuch außerhalb des üblichen Wartungspfads auf. Eine vage Freigabekarte wird dadurch nicht nützlich. Die Informationen müssen enthalten sein.

Den aufgelösten Pfad mit wegwerfbaren Zugangsdaten testen

Eine Konfigurationsprüfung braucht einen Ausführungstest, führen Sie ihn aber mit Zugangsdaten aus, die der Produktion nicht schaden können. Verwenden Sie einen Testhost, ein temporäres Konto und eine kontrollierte Umgebung. Erfassen Sie, sofern Ihr Betriebssystem es erlaubt, den clientseitigen Prozessbaum und die Netzwerkziele. Ziel ist zu bestätigen, welche ausführbare Datei startet, welche Argumente sie erhält und ob sie Verbindungen jenseits der erwarteten Route aufbaut.

Eine kompakte Prüfsequenz genügt für die meisten Host-Aliase:

1. Führen Sie ssh -G alias aus und speichern Sie die aufgelösten Einstellungen für hostname, user, port, proxycommand, proxyjump und Identität.
2. Verfolgen Sie jedes Include und jeden passenden Host- oder Match-Block, der diese Werte geliefert hat.
3. Lesen Sie jede lokale ausführbare Datei im Proxy- oder Match-Pfad, einschließlich Skripten und ihrer Konfigurationsdateien.
4. Führen Sie die Verbindung mit wegwerfbaren Zugangsdaten aus und prüfen Sie die tatsächlichen Jump Hosts, Hostschlüssel und lokalen Prozesse.
5. Widerrufen Sie die Test-Zugangsdaten nach dem Test und dokumentieren Sie die erwartete Route neben dem Alias.

Verlassen Sie sich nicht nur auf eine erfolgreiche Verbindung. Erfolg beweist, dass Bytes einen SSH-Server erreicht haben. Er beweist nicht, dass das richtige Programm sie transportiert hat, dass der beabsichtigte Host sie erhalten hat oder dass zuvor keine lokale Nebenwirkung aufgetreten ist.

Ein wenig Reibung ist hier angebracht. Wenn niemand die ausführbare Datei hinter einem ProxyCommand erklären kann, sollte niemand einen Agenten autorisieren, den Alias aufzurufen. Ersetzen oder entfernen Sie sie, oder halten Sie die Route außerhalb der Reichweite des Agenten, bis jemand dafür verantwortlich ist.

Eine kleine SSH-Oberfläche schlägt raffinierte Client-Konfiguration

Die sicherste SSH-Einrichtung für Agenten hat wenige benannte Ziele, feste Identitäten, explizite Jump Hosts und keine beliebigen Konfigurationsflags. Dafür braucht es keine universelle Richtliniensprache. Es braucht eine begrenzte Schnittstelle und eine Konfiguration, die bei der Prüfung unspektakulär bleibt.

Prüfen Sie erneut, wenn sich eines davon ändert: ein SSH-Client-Update, ein neues Bootstrap-Skript, ein Rollout des Konfigurationsmanagements, ein zusätzliches Include-Verzeichnis, eine neue Agentenlaufzeit oder ein neuer Jump Host. Diese Änderungen landen oft in getrennten Repositories. Genau deshalb verschlechtert sich der Verbindungspfad, ohne dass es jemand bemerkt.

Halten Sie den endgültigen Standard einfach: Bevor ein Remote-Befehl läuft, sollten Sie jede lokale ausführbare Datei benennen können, die SSH startet, jeden Host, den es kontaktiert, jede verwendete Identität und die Person, die diese Route freigegeben hat. Wenn das für einen Alias nicht möglich ist, ist er nicht bereit für autonome Nutzung.