ssh-agent unter Windows: Dienst starten, Schlüssel laden, Fehler beheben

29. Sept. 2026 · Termalin Team sshssh-agentwindowstutorial

Du hast deinen SSH-Schlüssel mit einer Passphrase versehen, und jetzt fragt Windows bei jedem git push und jedem ssh danach. Die Lösung ist der SSH-Agent – entsperre den Schlüssel einmal, und jede Verbindung danach signiert lautlos. Der Haken unter Windows: Es gibt nicht einen Agenten. Es gibt drei, die gleichzeitig laufen können, sie halten Schlüssel an getrennten Orten, und ein in den einen geladener Schlüssel ist für die anderen unsichtbar. Fast jedes „gestern ging es noch“-Agentenproblem unter Windows ist in Wahrheit ein Problem mit dem falschen Agenten. Dieser Leitfaden benennt sie also zuerst, bringt dann jeden zum Laufen und entschlüsselt am Ende die Fehler, die dir wirklich begegnen.

Die drei Agenten – und warum sie keine Schlüssel teilen

Agent	Kommt mit	Wo er lauscht	Welches `ssh` ihn sieht
OpenSSH Authentication Agent (ein Windows-Dienst)	dem nativen OpenSSH von Windows	Named Pipe `\\.\pipe\openssh-ssh-agent`	`ssh.exe` in `C:\Windows\System32\OpenSSH`
Der MSYS2-Agent (`ssh-agent`)	Git for Windows / Git Bash	ein Unix-artiger Socket, benannt durch `SSH_AUTH_SOCK`	das in Git Bash mitgelieferte `ssh`
Ein Linux-Agent	in deiner WSL-Distribution	ein Unix-Socket in dieser Distribution	`ssh`, das in WSL läuft

Die Lehre aus der Tabelle: ssh-add in Git Bash lädt einen Schlüssel in den MSYS2-Agenten, und das native Windows-ssh.exe sieht ihn nie – anderer Endpoint, anderer Schlüsselspeicher. Wähle einen Agenten, lade deine Schlüssel dort und nutze das passende ssh. Sie zu mischen ist die eigentliche Ursache der meisten Verwirrung weiter unten. Der Leitfaden zu ssh-agent und ssh-add (auf Englisch) behandelt die plattformübergreifende Mechanik; diese Seite ist die Windows-spezifische Hälfte.

Der eingebaute Dienst OpenSSH Authentication Agent

Aktuelle Windows 10 und 11 bringen OpenSSH mit und damit einen Windows-Dienst, der den Agenten betreibt – aber er ist standardmäßig aus. Aktiviere ihn einmal, aus einer erhöhten PowerShell (Als Administrator ausführen):

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

Automatic startet ihn bei jedem Hochfahren, das ist also eine einmalige Einrichtung. Prüfe das Ergebnis:

Get-Service ssh-agent | Select-Object Status, StartType

Du willst Running und Automatic. Von da an spricht ssh-add in einer normalen (Nicht-Git-Bash-)PowerShell oder cmd mit diesem Dienst:

ssh-add                                 # load default keys (id_ed25519, id_rsa, …)
ssh-add $env:USERPROFILE\.ssh\id_ed25519  # load a specific key
ssh-add -l                              # list loaded key fingerprints

ssh-add -l ist deine erste Diagnose bei jedem fehlgeschlagenen Login – wenn der erwartete Schlüssel nicht aufgelistet ist, kann der Agent nicht damit signieren, egal wie richtig alles andere aussieht.

Damit du ssh-add nicht immer neu tippst, lass die erste Verbindung den Schlüssel für dich laden. Trage das in %USERPROFILE%\.ssh\config ein (dieselbe ssh_config-Datei (auf Englisch), die OpenSSH überall liest):

Host *
    AddKeysToAgent yes

Jetzt fragt das erste ssh, das eine Passphrase braucht, einmal nach und lädt den Schlüssel als Nebeneffekt in den Dienst. Weil das native Windows-git und -ssh beide diesen Dienst nutzen, funktioniert auch git push fortan lautlos.

Fehler 1058: „unable to start the ssh-agent service“

Du führst Start-Service ssh-agent aus und bekommst:

Start-Service : Service 'OpenSSH Authentication Agent (ssh-agent)' cannot be started due to the following error:
Cannot start service ssh-agent on computer '.'.
... error 1058 ...

Fehler 1058 heißt, der Dienst ist deaktiviert – Windows startet keinen Dienst, dessen Starttyp Disabled ist, und Start-Service ändert das nicht für dich. Korrigiere erst den Starttyp, dann starte ihn (erhöhte PowerShell):

Set-Service ssh-agent -StartupType Manual
Start-Service ssh-agent

Manual reicht, um ihn bei Bedarf zu starten; nimm Automatic, wenn er bei jedem Hochfahren laufen soll. Auf einer verwalteten Maschine oder in einer Domäne hat ihn womöglich eine Gruppenrichtlinie deaktiviert – dann muss dein Admin den Dienst erst freigeben, bevor das hält.

„error connecting to agent: No such file or directory“

Dieser kommt vom Git-Bash-/MSYS2-ssh, nicht vom Windows-Dienst. Er heißt, dass diesem ssh gesagt wurde, wo ein Agenten-Socket zu finden ist – über SSH_AUTH_SOCK –, und dort nichts ist. Zwei häufige Ursachen:

In dieser Shell läuft kein Agent. Git Bash startet keinen für dich. Starte ihn in der Shell, die du gerade benutzt:
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
```
Das eval ist entscheidend: ssh-agent -s gibt die Variablen nur aus; das eval setzt sie, damit ssh den Socket findet. ssh-agent nackt auszuführen und sich zu wundern, warum sich nichts ändert, ist der klassische Fehltritt.
SSH_AUTH_SOCK ist veraltet. Eine Variable, die von einer früheren Sitzung, einem Login-Profil oder einem anderen Tool gesetzt wurde, zeigt auf einen Socket, den es nicht mehr gibt. Prüfe sie mit echo $SSH_AUTH_SOCK, dann entweder leere sie und starte einen frischen Agenten, oder korrigiere sie, damit sie auf einen lebenden zeigt.

Wenn du aus Git Bash heraus lieber den Windows-Dienst nutzt, ruf die native Binärdatei direkt auf – /c/Windows/System32/OpenSSH/ssh.exe – statt des MSYS2-ssh in deinem PATH. Dann erreicht Git Bash dieselben Schlüssel, die du in den Dienst geladen hast, und SSH_AUTH_SOCK spielt keine Rolle mehr.

Schlüssel in WSL

WSL ist ein eigenes Linux-System, hat also seinen eigenen Agenten, sein eigenes ~/.ssh und sein eigenes SSH_AUTH_SOCK. Schlüssel, die auf der Windows-Seite geladen sind, sind in deiner Distribution nicht sichtbar und umgekehrt. Du hast zwei ehrliche Möglichkeiten:

Betreibe einen Agenten in WSL auf die gewöhnliche Linux-Art – eval "$(ssh-agent -s)" und ssh-add, oder AddKeysToAgent yes in der ~/.ssh/config der Distribution. Einfach, vollständig isoliert und im ssh-add-Leitfaden (auf Englisch) behandelt.
Baue eine Brücke zum Windows-Agenten, damit sich beide Welten einen Schlüsselspeicher teilen. Das übliche Rezept leitet die Windows-Named-Pipe in einen Unix-Socket um, auf den WSLs SSH_AUTH_SOCK zeigt, mithilfe von npiperelay.exe zusammen mit socat. Einmal eingerichtet funktioniert das gut, aber es sind mehr bewegliche Teile – greif nur dann dazu, wenn du denselben Schlüssel wirklich auf beiden Seiten brauchst.

Was du auch wählst, denk daran: ssh-add -l in WSL ist eine andere Frage als ssh-add -l in PowerShell. Stell beim Debuggen die richtige.

Wenn ssh-add -l deinen Schlüssel zeigt und der Server trotzdem Permission denied (publickey) sagt, hat der Agent seine Arbeit getan – das Problem ist weitergewandert zu authorized_keys auf dem Server, zum falschen Benutzer oder zum falschen angebotenen Schlüssel. Das ist eine eigene Checkliste: Permission denied (publickey), der Reihe nach behoben (auf Englisch). Und bevor du den Agenten mit ssh -A auf eine entfernte Maschine weiterleitest, lies, warum Agent-Weiterleitung bequem und gefährlich ist (auf Englisch) – sie gibt die Live-Nutzung deiner Schlüssel am anderen Ende preis.

Wie Termalin das unter Windows löst

Wenn das Jonglieren mit Diensten, Sockets und drei Schlüsselspeichern mehr ist, als du dir überlegen willst, dann ist das der Arbeitsablauf, den Termalin eingebaut hat. Es betreibt seinen eigenen Schlüssel-Agenten auf einer Windows-Named-Pipe, \\.\pipe\termalin-ssh-agent, und stellt die Schlüssel, die du in der App schon entsperrt hast, über das Standard-ssh-agent-Protokoll bereit – ein Tool, das dieses Protokoll spricht, kann also darüber signieren, ohne OS-Dienst zum Aktivieren, ohne eval-Zeile und ohne manuelles ssh-add. Die privaten Schlüssel bleiben in der laufenden App und landen nie auf der Platte. Der Sinn dieses Agenten: Termalins eigener MCP-Server authentifiziert sich bei deinen Servern mit deinen Schlüsseln, ohne das Schlüsselmaterial je selbst zu halten – der Agent signiert, der Aufrufer sieht das Geheimnis nie. Es ist dieselbe Einmal-entsperren-Idee wie beim OpenSSH-Dienst, nur mit der Windows-Einrichtung von deinem Tisch genommen.

Termalin ist ein kostenloser, plattformübergreifender SSH-Client, dessen eingebauter Agent deine Schlüssel einmal entsperrt und in deinem Namen signiert – lade es herunter oder lies, wie es deine Schlüssel sicher verwahrt.