5

In the course of trying to accomplish a more complicated task (involving hardware security keys and GPG keys for SSH authentication), I have run into an ornery ssh-add utility on my Windows 10 machine. Quite simply, my ssh-add fails to connect to the agent, while all other ssh functions work fine.

When I run ssh-add -L on Powershell 7.0.3, I get the following output:

Error connecting to agent: No such file or directory

However, my ssh-agent service seems to be running just fine:

C:\Users\[me]> get-service ssh-agent

Status   Name               DisplayName
------   ----               -----------
Running  ssh-agent          OpenSSH Authentication Agent

C:\Users\[me]> get-service ssh-agent | select *

UserName            : LocalSystem
Description         : Agent to hold private keys used for public key authentication.
DelayedAutoStart    : False
BinaryPathName      : C:\WINDOWS\System32\OpenSSH\ssh-agent.exe
StartupType         : Automatic
Name                : ssh-agent
RequiredServices    : {}
CanPauseAndContinue : False
CanShutdown         : False
CanStop             : True
DisplayName         : OpenSSH Authentication Agent
DependentServices   : {}
MachineName         : .
ServiceName         : ssh-agent
ServicesDependedOn  : {}
StartType           : Automatic
ServiceHandle       :
Status              : Running
ServiceType         : Win32OwnProcess
Site                :
Container           :


C:\Users\[me]> get-command ssh-add

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     ssh-add.exe                                        7.7.2.1    C:\WINDOWS\System32\OpenSSH\ssh-add.exe

Furthermore, I have my standard public/private SSH keypair in the default location (C:\Users\[me]\.ssh\id_rsa, C:\Users\[me]\.ssh\id_rsa.pub). I've used this key extensively on GitHub, and ssh itself still works fine in Powershell:

C:\Users\[me]> ssh -T [email protected]
Enter passphrase for key 'C:\Users\[me]/.ssh/id_rsa':
Hi [me]! You've successfully authenticated, but GitHub does not provide shell access.

So, given every other aspect of OpenSSH seems to be working fine, why would ssh-add be misbehaving?

Things I have tried to repair it:

  • Removing other SSH utilities from my PATH (e.g. those added by Git installation).
  • Disabling/re-enabling the Windows optional feature "SSH Client" (and its "SSH Server" counterpart, which I don't think I need).
  • Installing a more recent version of OpenSSH via Chocolatey (https://chocolatey.org/packages/openssh), and pointing all commands to that installation via PATH modification.
  • Backing up and removing my .ssh folder, generating a new key (via ssh-keygen), and starting from scratch.
  • Changing the startup type of the ssh-agent service between automatic, manual, and disabled

None of the aforementioned activities seemed to have any effect whatsoever. All other ssh tools worked fine (assuming the optional feature was enabled, and service was running), but ssh-add did not.

What other recommendations do others have for diagnosing this ornery utility?

5 Answers 5

2

As it turns out, in my case I had an outdated environment variable in my PowerShell/Cmd environment, SSH_AUTH_SOCK. It was pointing to a nonexistent socket/pipe, which led the ssh-add utility to (rightfully) complain that there was "no such file or directory."

Simply removing the environment variable altogether did the trick of allowing ssh-add to run without error:

C:\Users\[me]> Get-Item Env:\SSH_AUTH_SOCK

Name                           Value
----                           -----
SSH_AUTH_SOCK                  \\.\pipe\this-socket-never-existed

C:\Users\[me]> Remove-Item Env:\SSH_AUTH_SOCK

Now, the reason why I had SSH_AUTH_SOCK set in the first place was because I wanted to build a bridge between my hardware security key (Yubikey) and the Windows 10 native OpenSSH agent. In my case, I was trying (and failing) to get benpye's WSL SSH Pageant to run on startup.

However, when the program is in fact running as the documentation recommends:

C:\Users\[me]> wsl-ssh-pageant.exe --winssh ssh-pageant

C:\Users\[me]> $Env:SSH_AUTH_SOCK = "\\.\pipe\ssh-pageant"

I found that not only does ssh-add run without error, it also recognizes and uses my Yubikey's public authentication key when queried.

C:\Users\[me]> ssh-add -L
ssh-rsa [key]

So the TL;DR is that my oversight about an outdated environment variable led to ssh-add terminating with a "file not found" error.

1
  • 1
    When WSL SSH Pageant is properly running, I don't think you need "OpenSSH Authentication Agent".
    – Jamie
    Commented Mar 3, 2021 at 1:48
2

I had a similar problem, though in my case it was more generic, like the problems many others here have run into. In general, these problems arise from a mismatch between ssh-agent and ssh-add. For example, I had the Windows agent running but my path pointed first to the Git for Windows ssh-add.

ANY inconsistency between agent and add leads to a situation where some things work and some don't. A common result is the dreaded Permission denied (publickey) error. The typical scenario is that testing the connection with ssh -T [email protected] works but operations like git push fail. This happens because the ssh command an run against multiple agents. However, an agent's ssh key database is proprietary so can only be accessed by same-vendor commands.

I can't offer a recipe to fix this for all environments, but the principle of knowing that you have a known good environment is key. If you're seeing odd or inexplicable behavior in ssh, it's not likely a bug in vendor software. First check that your environment variables and path point to the same ssh installation. Then verify which gitconfig and ssh config files they are using and that the data in them don't conflict with your ssh installation. Finally, if you're working in an IDE, make sure its configuration matches all the above.

1

I think the author uses the bundled OpenSSH come with Windows, and one issue happened for me is that Git by default uses the ssh bundled with itself (for example, check the output of which ssh-add inside Git Bash, and compare it with the Get-Command ssh-add inside PowerShell).

One solution is to let Git use the built-in SSH by:

# "C:/Windows/System32/OpenSSH/ssh.exe" is the result of Get-Command ssh
git config --global core.sshcommand "C:/Windows/System32/OpenSSH/ssh.exe"

Credit: https://poshsecurity.com/blog/using-the-openssh-client-included-in-windows-10-1809-as-your-gits-ssh-client

0

I had an issue much similar to this one and I happened to solve it simply by connecting my work PC with its domain through my company VPN. Here you'll find some others having the same issue.

0

When I reinstalled git, there was an option to use windows openssh instead of git's own ssh, and then my git bash was able to access windows' own ssh-agent using ssh-add -l,VSCODE successfully synched the change.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .