WardtermSSH-Client
DE
Herunterladen

Risiken von SSH Agent Forwarding und was Sie stattdessen nutzen

Bei ssh -A bleibt Ihr Agent auf Ihrem Computer, aber der Zielhost erhält einen Socket, der mit ihm spricht. Root auf diesem Host kann den Socket nutzen, um sich überall anzumelden, wo Ihre Schlüssel funktionieren, solange Sie verbunden bleiben. Der Schlüssel selbst wird nicht kopiert. Nutzen Sie stattdessen ssh -J, um über einen Jump-Host zu gehen.

Keine Lust, ssh-askpass einzurichten? Wardterm bringt einen eigenen Agent mit, den nur die Server nutzen, die Sie wählen. Zeigen

Aktualisiert am . Ausgeführt mit OpenSSH 10.3 unter macOS und einem separaten Test-ssh-agent gegen OpenSSH 10.0 unter Debian 13.

Was -A tut

Ohne Weiterleitung nützen Ihnen Ihre Schlüssel nichts, sobald Sie auf einem Server sind, ein zweiter Sprung von dort kann sie also nicht verwenden. ssh -A löst das, indem es den Zielhost wieder mit Ihrem Agent verbindet:

ssh -A user@server
echo "$SSH_AUTH_SOCK"
/tmp/ssh-G63yAM532X/agent.1441

Dieser Pfad ist ein Unix-Socket auf dem Server. Alles, was man dorthin sendet, läuft zurück zum Agent auf Ihrem Computer, der signiert, was verlangt wird, und das Ergebnis zurückgibt. Der Server erhält den privaten Schlüssel nie.

Der Ort hängt von der Version des Servers ab. Unter OpenSSH 10.0 sahen wir /tmp/ssh-XXXXXXXXXX/agent.<pid>. Version 10.1 hat die Agent-Sockets nach ~/.ssh/agent/ verlegt.

Wie Sie Schlüssel zuerst in einen lokalen Agent laden, zeigt ssh-agent und der macOS-Schlüsselbund.

Was Root auf dem Zielhost tun kann

Dateirechte schützen den Socket vor anderen normalen Benutzern, und Root ignoriert diese Rechte. Wir haben das auf einem Server getestet, während ein Benutzer mit -A verbunden war. Als Root:

# find /tmp -type s -name 'agent.*'
/tmp/ssh-G63yAM532X/agent.1441

# SSH_AUTH_SOCK=/tmp/ssh-G63yAM532X/agent.1441 ssh-add -l
256 SHA256:IikDwOZxEooOrmm+d3MXJXlobc7rwEyUrQNIBXHzXaU key (ED25519)

# SSH_AUTH_SOCK=/tmp/ssh-G63yAM532X/agent.1441 ssh user@203.0.113.11 id -un
user

Root hat den Schlüssel also benutzt, um sich an einer anderen Maschine anzumelden, ohne dass beim Benutzer eine Rückfrage kam. Hier das ganze Bild:

  • Das geht: jeden Schlüssel in Ihrem Agent benutzen, um sich an jedem Server oder Dienst anzumelden, der ihn akzeptiert, auch an einem Konto bei einem Code-Hosting-Dienst. Außerdem lassen sich Ihre öffentlichen Schlüssel auflisten und Schlüssel aus Ihrem Agent entfernen: ssh-add -D auf dem Server ausgeführt hat unseren lokalen Agent geleert.
  • Das geht nicht: den privaten Schlüssel kopieren. Der Agent gibt ihn nicht heraus. Ein gestohlener Socket funktioniert nicht mehr, sobald Ihre Sitzung endet, und wir haben bestätigt, dass der Socket dann verschwindet.
  • Ein anderer normaler Benutzer wurde abgewiesen: Error connecting to agent: Permission denied.

"Root" schließt hier jeden ein, der in den Server eingebrochen ist und Root-Rechte erlangt hat. Eine Anmeldung, die während Ihrer Verbindung erfolgt, kann einen eigenen Schlüssel auf dem Ziel hinterlegen und den Zugang noch lange nach Ihrem Weggang behalten. Deshalb beruhigt die kurze Lebensdauer des Sockets weniger, als es scheint.

Die Alternative: ProxyJump

Die meisten nutzen die Weiterleitung, um durch einen Bastion-Host zu kommen. Mit -J baut Ihr Computer eine verschlüsselte Verbindung durch den Jump-Host zum Zielserver auf, und die Schlüssel werden nur von Ihrem Computer aus verwendet:

ssh -J user@bastion user@server

Oder in ~/.ssh/config:

Host server
    HostName 10.0.0.5
    ProxyJump user@bastion

In unserem Test funktionierte die Verbindung, $SSH_AUTH_SOCK war auf dem Ziel leer, und auf dem Jump-Host gab es keinen Agent-Socket. Ein kompromittierter Bastion-Host bekommt nichts, was er nutzen könnte. Siehe ProxyJump und Jump-Hosts.

Wenn Sie Forwarding wirklich brauchen

Ein typischer Fall ist git pull auf einem Server mit Ihren persönlichen Zugangsdaten. Fragen Sie zuerst, ob ein Deploy-Schlüssel für genau dieses Repository, der auf dem Server liegt, ausreicht. Brauchen Sie die Weiterleitung trotzdem, verringern Sie, was sie freigibt.

Vor jeder Nutzung nachfragen: ssh-add -c

ssh-add -c ~/.ssh/id_ed25519

Ihr Agent bittet nun bei jeder Nutzung des Schlüssels auf Ihrem eigenen Bildschirm um Bestätigung, eine unerwartete Anfrage fällt also auf. Lehnen Sie ab, scheitert die Anmeldung:

sign_and_send_pubkey: signing failed for ED25519 "key" from agent: agent refused operation

Dafür braucht Ihr Computer ein ssh-askpass-Programm, das Sie eventuell installieren müssen. Unter macOS fanden wir standardmäßig keines. Ohne eines sollten Sie testen, bevor Sie sich darauf verlassen.

Weniger Schlüssel freigeben

  • Betreiben Sie einen separaten Agent, der nur den benötigten Schlüssel enthält, und leiten Sie diesen mit ForwardAgent /path/to/agent.sock im Block des Hosts weiter.
  • Begrenzen Sie mit ssh-add -t 1h ~/.ssh/id_ed25519, wie lange Schlüssel geladen bleiben.
  • Verwenden Sie einen Schlüssel, der nur öffnet, was diese Aufgabe braucht, und nicht Ihren Hauptschlüssel.
  • Sehen Sie sich Zielbeschränkungen an, ssh-add -h, die einschränken, wo ein Schlüssel benutzt werden darf.

Nur an benannte Hosts weiterleiten

Host build-box
    ForwardAgent yes

Setzen Sie ForwardAgent yes niemals unter Host *. Standardmäßig ist es aus, und das ist richtig. Ein einziges unachtsames ssh zu einem Server, dem Sie nicht voll vertrauen, würde diesem Server Ihren Agent für die Dauer der Sitzung übergeben.

Wann es vertretbar ist

Es ist ein vernünftiger Kompromiss, wenn alles Folgende zutrifft: Sie vertrauen jedem, der auf diesem Host Root hat, und Sie vertrauen darauf, dass der Host nicht kompromittiert ist; die Sitzung ist kurz; und Sie könnten die Aufgabe nicht mit -J oder einem Deploy-Schlüssel erledigen. Vermeiden Sie es auf gemeinsam genutzten Servern, auf aus dem Internet erreichbaren Hosts, die andere verwalten, und auf allem, wo Sie Ihren entsperrten Laptop nicht liegen lassen würden.

Auf einem Server ausschalten

AllowAgentForwarding no

Mit dieser Zeile in der sshd_config verband sich ssh -A in unserem Test normal, aber es erschien kein Socket. Das Handbuch weist darauf hin, dass Benutzer mit Shell-Zugang trotzdem eigene Weiterleitungen einrichten können. Betrachten Sie das also als Standard, der Versehen verhindert, und nicht als harte Sperre.

Fragen

Ist SSH-Agent-Forwarding sicher?

Nur auf Servern, bei denen Sie allen mit Root-Rechten vertrauen. Solange Sie verbunden sind, kann Root Ihre Schlüssel nutzen, um sich anderswo als Sie anzumelden. Den privaten Schlüssel kopieren kann Root nicht.

Was ist der Unterschied zwischen ssh -A und ssh -J?

-A lässt den entfernten Host Ihren Agent nutzen. -J führt über einen Jump-Host zum Ziel, und die Schlüssel werden nur von Ihrem Rechner aus verwendet: Der Jump-Host hat nichts in der Hand.

Wie schalte ich Agent-Forwarding auf einem Server ab?

Tragen Sie AllowAgentForwarding no in sshd_config ein und laden Sie sshd neu. Benutzer mit Shell können sich eigene Weiterleitungen bauen, es ist also ein Schutz vor Versehen, keine harte Grenze.

Quellen

Mehr zu Server absichern

Alle Anleitungen