ssh-agent und ssh-add in der Praxis: hör auf, deine Passphrase zu tippen

ssh-agent ist ein Hintergrundprogramm, das deine entsperrten privaten Schlüssel im Speicher hält und Authentifizierungs-Challenges mit ihnen signiert, sodass du die Passphrase eines Schlüssels einmal pro Sitzung eingibst statt einmal pro Verbindung. ssh-add ist der Befehl, der Schlüssel in ihn lädt.

Du hast das Richtige getan und deinem SSH-Schlüssel eine Passphrase verpasst – und jetzt tippst du sie zum fünften Mal vor dem Mittagessen. Die Lösung gibt es seit Jahrzehnten: den SSH-Agenten. Entsperr den Schlüssel einmal, und jede Verbindung danach authentifiziert sich still. Der Haken: Das „einmal“ klappt nur, wenn der Agent tatsächlich läuft, deine Shell ihn findet und der Schlüssel geladen ist – drei getrennte Dinge, jedes mit seiner eigenen Art zu scheitern. Das ist der praktische Leitfaden: den Agenten auf jedem Betriebssystem starten, ihn mit ssh-add steuern, das Ganze automatisch machen und die zwei Fehler entschlüsseln, die fast allen Agenten-Ärger ausmachen.

Was der Agent ist, in einem Absatz

ssh-agent ist ein kleiner Hintergrundprozess, der deine entschlüsselten privaten Schlüssel im Speicher hält – nie auf der Platte. Wenn ein Server dich herausfordert, reicht ssh die Challenge an den Agenten, der Agent signiert sie mit dem Schlüssel im Speicher, und nur die Signatur geht zurück – der Schlüssel selbst verlässt den Agenten nie, berührt nie die Leitung und bleibt auf der Platte verschlüsselt. Eine Passphrase-Abfrage, um den Schlüssel zu laden, dann wird jede spätere Verbindung aus dem Speicher bedient. Das ist das ganze Denkmodell: Der Agent ist ein Signierdienst, kein Schlüsseltresor, aus dem jemand liest – er bewacht das Geheimnis und gibt immer nur Signaturen heraus. (Genau diese Eigenschaft ist auch der Sicherheitshaken, und sie bekommt am Ende einen eigenen Abschnitt.)

Unter Windows? Lies zuerst den Windows-Leitfaden

Wenn du über error connecting to agent: No such file or directory hierhergekommen bist: Diese Meldung ist Windows-spezifisch – sie kommt vom ssh aus Git Bash / MSYS2, und ihre Lösungen ebenso: der Dienst OpenSSH Authentication Agent, der eigene Agent von Git Bash und Fehler 1058. Sie stehen alle in ssh-agent unter Windows. Alles weiter unten ist der plattformübergreifende Arbeitsablauf aus ssh-agent und ssh-add, und die Fehler, die er entschlüsselt, sind die des OpenSSH-Clients selbst: Could not open a connection to your authentication agent und The agent has no identities.

Den Agenten starten, je Betriebssystem

Linux – eval "$(ssh-agent -s)"

Bei einem Desktop-Login hast du mit ziemlicher Sicherheit schon einen Agenten – entweder einen systemd-User-Dienst oder GNOME Keyring in der Rolle –, mit SSH_AUTH_SOCK, das für deine ganze Sitzung exportiert ist. Teste mit ssh-add -l. Wenn nichts antwortet (üblich bei einem nackten SSH-Login, in Containern oder auf minimalen Servern), starte einen von Hand:

eval "$(ssh-agent -s)"

Das eval ist entscheidend. ssh-agent -s gibt die Variablen SSH_AUTH_SOCK und SSH_AGENT_PID nur aus; das eval ist das, was sie in deiner aktuellen Shell setzt, damit ssh den Socket findet. ssh-agent nackt auszuführen und sich zu wundern, warum sich nichts ändert, ist der häufigste Weg, einen Agenten zu „starten“, den kein Werkzeug sehen kann.

macOS – launchd betreibt ihn für dich

launchd betreibt ab dem Login einen Agenten für dich – es gibt nichts zu starten. Der macOS-spezifische Gewinn ist die Keychain-Integration weiter unten.

ssh-agent unter Windows starten

Modernes Windows liefert einen Dienst OpenSSH Authentication Agent, aber er ist auf manuellen Start gestellt und läuft standardmäßig nicht. Aktiviere ihn einmal aus einer PowerShell mit erhöhten Rechten:

Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent

Danach funktioniert ssh-add in jedem Terminal – PowerShell, cmd oder dem Windows-OpenSSH-Client unter Git Bash – und der Agent übersteht Reboots. Eine Falle: Git for Windows bringt sein eigenes ssh und ssh-agent mit, und in Git Bash kann das ssh auf deinem PATH dieses sein, das mit einem separaten Agenten spricht. Wenn ssh-add -l zwischen Git Bash und PowerShell nicht übereinstimmt, richte Git auf den System-Client, damit sich beide einen Agenten teilen:

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

Die vollständige Anleitung – der Dienst, Git Bash und das Laden von Schlüsseln beim Login – steht in ssh-agent unter Windows.

Ihn mit ssh-add steuern

Einen Schlüssel laden: ssh-add ~/.ssh/id_ed25519

ssh-add                          # load the default keys (id_ed25519, id_rsa, …)
ssh-add ~/.ssh/id_ed25519        # load a specific key (prompts for the passphrase once)

Ohne Pfad lädt ssh-add die Standard-Schlüsselnamen aus ~/.ssh; gib ihm einen Pfad, um einen bestimmten Schlüssel zu laden. So oder so fragt es einmal nach der Passphrase und hält dann den entschlüsselten Schlüssel im Speicher.

Anzeigen, was geladen ist: ssh-add -l

ssh-add -l                       # list fingerprints of loaded keys
ssh-add -L                       # print the full public keys
ssh-add -d ~/.ssh/id_ed25519     # remove one key
ssh-add -D                       # remove all keys

ssh-add -l ist die erste Diagnose bei jedem Auth-Problem: Wenn der erwartete Schlüssel nicht in dieser Liste steht, kann der Agent nicht mit ihm signieren, wie richtig auch sonst alles aussieht.

Ein ssh-agent-Timeout setzen: ssh-add -t

Zwei Flags lohnt es sich zur Gewohnheit zu machen:

• -t setzt eine Lebensdauer. ssh-add -t 3600 ~/.ssh/id_ed25519 lädt den Schlüssel für eine Stunde; danach vergisst der Agent ihn, und die nächste Nutzung fragt erneut. Ein Schlüssel, der bei drei Wochen Uptime entsperrt im Speicher liegt, ist ein Schlüssel, der lange nutzbar bleibt, nachdem du längst nicht mehr an ihn denkst.
• -c verlangt eine Bestätigung. Jede Signieranfrage öffnet eine lokale Abfrage, bevor der Agent antwortet. Leicht lästig, genau richtig für hochwertige Schlüssel.

Automatisch machen: AddKeysToAgent

Das manuelle ssh-add-Ritual verschwindet mit einer Zeile in ~/.ssh/config (auf Englisch):

Host *
    AddKeysToAgent yes

Jetzt fragt das erste ssh, das einen Schlüssel braucht, einmal nach der Passphrase und lädt den Schlüssel als Nebeneffekt in den Agenten. Kein separater Befehl zu merken – die Abfrage hört einfach auf, wiederzukehren. Du kannst auch eine Lebensdauer setzen (AddKeysToAgent 1h), um das -t-Verhalten ohne das Flag zu bekommen.

macOS: Reboots mit der Keychain überstehen. Standardmäßig vergisst der Agent Schlüssel, wenn er neu startet. macOS kann die Passphrase in deiner Login-Keychain speichern, sodass Schlüssel ohne erneutes Tippen neu geladen werden:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

und in ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes

Danach wird die Passphrase-Frage beim Login von der Keychain beantwortet, und du siehst sie nie wieder – während die Schlüsseldatei auf der Platte verschlüsselt bleibt.

Die zwei Fehler, auf die alle stoßen

Could not open a connection to your authentication agent – ssh-add findet keinen Agenten. Entweder läuft keiner, oder einer läuft, aber diese Shell hat SSH_AUTH_SOCK nicht gesetzt. Die Lösung ist der Start je Betriebssystem oben: die Zeile eval "$(ssh-agent -s)" unter Linux (prüf zuerst, ob deine Desktop-Sitzung schon einen bereitstellt – einen zweiten Agenten pro Terminal zu starten verstreut geladene Schlüssel nur über mehrere Prozesse), der Dienststart unter Windows. Du begegnest dem auch in Cron-Jobs und CI, wo keine Login-Sitzung je die Variable exportiert hat.

The agent has no identities. – das umgekehrte Problem: Der Agent ist in Ordnung, aber nichts ist geladen. Mach ssh-add mit deinem Schlüssel. Wenn er geladen war und verschwand, lief eine -t-Lebensdauer ab oder der Agent startete neu – was genau das ist, wofür AddKeysToAgent yes und die macOS-Keychain da sind.

Und der dritte Fall: Der Agent sieht perfekt aus – ssh-add -l zeigt den Schlüssel –, aber der Server sagt trotzdem Permission denied (publickey). Das ist kein Agenten-Problem mehr; arbeite die publickey-Checkliste durch – falscher Benutzer, falscher angebotener Schlüssel, Berechtigungen der authorized_keys.

Ein entsperrter Agent ist ein aktives Zugangsmittel

Der Agent gibt den Schlüssel nie preis – aber der Socket ist ein Signierorakel: Er signiert für jeden, der ihn erreicht, und fragt nie, wer fragt. Auf deiner eigenen Maschine ist das in Ordnung – der Socket liegt in einem privaten, benutzereigenen Verzeichnis, das nur du lesen kannst. Gefährlich wird die Form des verwirrten Stellvertreters (confused deputy): wenn der Socket für etwas erreichbar wird, das du nicht beabsichtigt hast – ein weitergeleiteter Agent auf einem geteilten Bastion-Host oder ein Prozess, der als dein Benutzer läuft und dem du nicht traust –, kann dieses Etwas sich bei jedem Server, den deine Schlüssel erreichen, als du authentifizieren, ohne den Schlüssel je zu sehen. Dass der Schlüssel nie austritt, ist nur die halbe Garantie; zu kontrollieren, wer ihn nutzen darf, ist die andere Hälfte – und darum lohnt sich die kleine Mühe der Agenten-Hygiene.

• Gib Schlüsseln eine Lebensdauer (-t oder eine Lebensdauer bei AddKeysToAgent), damit ein untätiger Agent von selbst kalt wird.
• Sperr den Agenten, wenn du weggehst: ssh-add -x sperrt ihn hinter einem Passwort, ssh-add -X entsperrt; ssh-add -D wirft einfach alles weg.
• Nutze -c für die Schlüssel, die bis in die Produktion reichen.
• Leite den Agenten nicht standardmäßig weiter. ssh -A – ssh agent forwarding – legt die Live-Nutzung deiner Schlüssel auf dem Remote-Host offen, sodass jeder mit root dort für die Dauer deiner Sitzung als du signieren kann. Das verdient eine eigene Lektüre: ssh agent forwarding ist bequem und gefährlich (auf Englisch).

Wie Termalin das löst

Termalin baut diesen ganzen Arbeitsablauf ein, mit abgeschliffenen scharfen Kanten. Sein Schlüssel-Agent entsperrt deine Schlüssel einmal und signiert in deinem Namen – kein OS-Dienst zu aktivieren, keine eval-Zeile, kein Socket pro Shell, den man verlieren kann. Das Zwischenspeichern der Passphrase kommt standardmäßig mit einem Re-Lock-Timeout, also die ssh-add -t-Gewohnheit, für dich erzwungen statt von dir erinnert. Und weil er das Standard-ssh-agent-Protokoll spricht, signieren git und deine bestehenden CLI-Tools unverändert durch ihn – er ersetzt das Ritual, nicht deine Toolchain.

---

Termalin ist ein kostenloser, plattformübergreifender SSH-Client, dessen integrierter Agent deine Schlüssel einmal entsperrt und per Timer wieder sperrt – lade es herunter oder lies, wie es deine Schlüssel sicher verwahrt.