SSH-Agent-Forwarding: Sicherheitsrisiko & ProxyJump-Guide

SSH-Agent-Forwarding über das Flag -A oder die Direktive ForwardAgent yes ermöglicht die Nutzung lokaler privater Schlüssel über zwischengeschaltete Bastion-Hosts hinweg, ohne sie remote zu kopieren. Dieser Mechanismus erstellt jedoch einen UNIX-Socket, den jeder Benutzer mit Root-Rechten auf dem Jump-Server kapern kann, um sich bei anderen Systemen in Ihrem Netzwerk zu authentifizieren.

Die Funktionsweise des Socket-Hijackings beim SSH-Agent-Forwarding

OpenSSH speichert den Socket für die Agent-Kommunikation in einem temporären Pfad, der durch die Umgebungsvariable SSH_AUTH_SOCK auf dem Remote-Host definiert wird, typischerweise unter /tmp/ssh-XXXXXXXXXX/agent.<ppid>. Während dieser Dateideskriptor standardmäßig auf den verbundenen Systembenutzer beschränkt ist, besitzt der Benutzer root oder jeder Prozess mit Systemrechten auf diesem Zwischenserver Lese- und Schreibzugriff auf den Socket.

Wenn ein Angreifer einen Jump-Server kompromittiert, muss er Ihre privaten Schlüssel nicht extrahieren, da diese ausschließlich im Speicher Ihres lokalen Clients verbleiben. Stattdessen verweist der Angreifer lediglich auf die gekaperte Umgebungsvariable und fordert kryptografische Signaturen direkt von Ihrem aktiven lokalen Agenten an, solange Ihre Sitzung verbunden bleibt:

# Locate active agent sockets from other connected users on the bastion
ls -la /tmp/ssh-*/agent.*

# Hijack the socket to authenticate toward internal infrastructure
export SSH_AUTH_SOCK=/tmp/ssh-AbCdEf1234/agent.5678
ssh [email protected]

Ihr lokaler Client, auf dem ssh-agent läuft, signiert die eingehende Challenge des Ziel-Hosts, da er nicht zwischen von Ihnen initiierten Befehlen und Anfragen des Angreifers unterscheiden kann. Dieses Sicherheitsrisiko verwandelt jede gemeinsam genutzte oder vorgelagerte Bastion in eine direkte Brücke für horizontale Rechteausweitung in Ihrer Infrastruktur.

Sicherheitsvergleich zwischen Agent-Forwarding und ProxyJump

Die ProxyJump-Direktive, die in modernen OpenSSH-Versionen eingeführt wurde und über das Befehlszeilen-Flag -J verfügbar ist, eliminiert die Notwendigkeit vollständig, einen Authentifizierungs-Agenten auf Zwischen-Hosts offenzulegen. Mit ProxyJump baut Ihr lokaler SSH-Client einen Ende-zu-Ende-verschlüsselten TCP-Stream direkt zum Zielsystem über standardmäßiges stdio auf und nutzt den Jump-Host rein als unwissenden Transport-Router.

Durch die Nutzung von ProxyJump sieht ein Angreifer, selbst wenn er während Ihrer Verbindung root auf der zwischengeschalteten Bastion kontrolliert, nur rohen verschlüsselten Datenverkehr zu Zielport 22. Er hat keinerlei Zugriff auf beliebige Authentifizierungssignaturen.

Bastion-Hosts sauber in ~/.ssh/config konfigurieren

OpenSSH erzwingt strikte Berechtigungen von 700 für das Verzeichnis ~/.ssh sowie 600 für die Datei config und private Schlüssel. Anstatt ForwardAgent yes global zu aktivieren – was erhebliche Sicherheitsrisiken birgt –, besteht die empfohlene Praxis darin, deklarative Routing-Blöcke in Ihrer lokalen Konfigurationsdatei zu definieren:

# Hardened ~/.ssh/config configuration
Host bastion
    HostName bastion.example.com
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Host internal-node
    HostName 10.0.1.50
    User deploy
    IdentityFile ~/.ssh/id_production
    ProxyJump bastion

Die Verbindung über ssh internal-node verbindet sich automatisch über bastion mittels Ende-zu-Ende-Authentifizierung. Moderne Infrastruktur-Setups sollten Ed25519-Schlüssel nutzen, die seit OpenSSH 6.5 (Januar 2014) unterstützt werden, oder hardwaregestützte FIDO2-Schlüssel (ed25519-sk), die seit OpenSSH 8.2 (Februar 2020) unterstützt werden. Beachten Sie, dass veraltete ssh-rsa-Signaturen mit SHA-1 seit OpenSSH 8.8 (September 2021) standardmäßig deaktiviert sind.

Sichere Jump-Sitzungen und mobile Workflows verwalten

Auf mobilen Plattformen bleiben Schlüssel, die im SSH- und Mosh-Terminal für iOS und Android termi1 generiert werden, im Hardware-Keystore oder der Secure Enclave geschützt, wodurch sichergestellt wird, dass private Schlüssel das Gerät niemals verlassen. Bei der Verwaltung von Remote-Servern über wechselhafte Mobilfunkverbindungen hält Mosh den Sitzungsstatus über WLAN- und Mobilfunkwechsel hinweg nahtlos mittels UDP-Ports 60000-61000 aufrecht.

Mosh unterstützt jedoch weder Portweiterleitung noch Agent-Tunneling. Beim Zugriff auf private Hosts ohne öffentliche IP-Adressen oder offene Ports ist der Einsatz von Mesh-Netzwerken wie privaten Mesh-Netzwerken ohne offene Ports (Prialo) oder Tailscale eine Alternative zu herkömmlichen Jump-Bastions. Ein Mesh-Overlay weist jedem Knoten und mobilen Client direkte private IP-Adressen zu, sodass Multi-Hop-SSH-Bastions oder Agent-Forwarding vollständig überflüssig werden.

Wenn klassische Bastion-Hosts zwingend erforderlich sind, verhindern mobile Terminalfunktionen wie dedizierte fn-, Ctrl- und Esc-Tasten Syntaxfehler in Produktiv-Prompts, während Funktionen wie Production Guard die Infrastruktur schützen, indem sie destruktive Befehle stoppen, bevor sie auf kritischen Hosts ausgeführt werden.

Häufig gestellte Fragen

Wann ist die Verwendung von ssh -A mit Agent-Forwarding akzeptabel?

SSH-Agent-Forwarding ist nur dann akzeptabel, wenn Sie sich vorübergehend mit vertrauenswürdigen Einzelbenutzerservern unter Ihrer direkten Kontrolle verbinden. Auf gemeinsam genutzten Servern, Bastions von Drittanbietern oder Jump-Hosts in öffentlichen Clouds legt das Weiterleiten des Agenten Ihren Socket offen und sollte stets durch ProxyJump ersetzt werden.

Kann ein Angreifer meinen privaten Schlüssel über einen gekaperten Socket extrahieren?

Private Schlüssel können nicht aus einem gekaperten ssh-agent-Socket extrahiert werden, da Schlüssel niemals den Speicher des Client-Geräts verlassen. Ein Angreifer kann den Socket lediglich missbrauchen, um gültige kryptografische Authentifizierungssignaturen gegenüber sekundären Servern zu erzeugen, solange Ihre SSH-Verbindung aktiv bleibt.

Wie ersetzt das ProxyJump-Flag ForwardAgent bei der Nutzung auf der Befehlszeile?

Das ProxyJump-Flag ersetzt Agent-Forwarding auf der Befehlszeile über die Syntax -J, ohne dass Konfigurationsänderungen erforderlich sind. Die Ausführung von ssh -J user@bastion user@destination baut einen Ende-zu-Ende-verschlüsselten Kanal direkt zum Ziel auf und umgeht die Erstellung eines Agent-Sockets auf dem Zwischenserver vollständig.

Unterstützt Mosh SSH-Agent-Forwarding oder Portweiterleitung?

Mosh unterstützt weder SSH-Agent-Forwarding noch TCP-Portweiterleitung oder X11-Weiterleitung, da es nach dem Verbindungsaufbau per SSH über UDP arbeitet. Benutzer, die private Infrastrukturen mit Mosh verwalten, sollten sich über ein Mesh-Netzwerk wie Prialo verbinden oder Standard-SSH für weitergeleitete Bastions nutzen.