Windows 10 error connecting to agent no such file or directory

@manojampalam here is my debug and an everything I tried:

ssh -V
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.4

Installed via scoop with:

sudo scoop install 7zip git win32-openssh 
[environment]::setenvironmentvariable('GIT_SSH', (resolve-path (scoop which ssh)), 'USER')
cd "C:\Users\TAD BNT\scoop\apps\win32-openssh\current\"
sudo .\install-sshd.ps1
sudo Set-Service ssh-agent -StartupType Automatic

Started the service:

Start-Service ssh-agent
Get-Service ssh-agent

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

Added the key:

 ssh-add.exe "C:\Users\TAD BNT/.ssh/svpd4895"
Enter passphrase for C:\Users\TAD BNT/.ssh/svpd4895:
Identity added: C:\Users\TAD BNT/.ssh/svpd4895 (C:\Users\TAD BNT/.ssh/svpd4895)

Now the ssh command:

ssh pd4895
(....)
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\TAD BNT/.ssh/svpd4895
debug3: failed to open file:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Enter passphrase for key 'C:\Users\TAD BNT/.ssh/svpd4895':

In my config file this server is set as:

host pd4895
  hostname svpd4895---
  user ---
  port ---
  IdentitiesOnly yes
  IdentityFile ~/.ssh/svpd4895

If I add AddKeysToAgent yes to my config file keys get automatically added to ssh-agent instead of me having to issue ssh-add path\key, but I still get the Enter passphrase for key message. It looks like there is some communication failure between the ssh client and the agent.

Also, I was reading previous comments again, and I don’t have an SSH_AUTH_SOCK set:

 gci env:SSH_AUTH_SOCK
gci : Cannot find path 'SSH_AUTH_SOCK' because it does not exist.
At line:1 char:1
+ gci env:SSH_AUTH_SOCK

However, when I’m using AddKeysToAgent yes my keys get added to the agent (I can see that with `ssh-add -L), so, apparently, the ssh client is somehow communicating with the agent.

I also tried to use only windows directory separators \ and .ssh\svpd4895 and the issue is the same.

What am I missing here?

The full output of the ssh -vvv is available here: https://gist.github.com/TCB13/aa582b24a08dead443d1179811831d92

Many thanks.

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?

I found that something in Windows10 is setting the path to ssh-agent as an env-var, but cannot cope with spaces in foldernames. Someone forgot to escape their inputs! (AAAAAAAARRRRGGGGH!).

To test: (in git-bash, which I’m currently using)

echo "$(ssh-agent)"

…gives what your env has setup (in my case: stupidly) for how it will find/access ssh-agent. I got:

SSH_AUTH_SOCK=/d/Windows10 Temporary Files/ssh-XXXXXXX/agent.YYYYY; export SSH_AUTH_SOCK;
SSH_AGENT_PID=54456; export SSH_AGENT_PID;
echo Agent pid 54456;

…oh look! Someone forgot that folders can have spaces, and didn’t bother to escape their inputs (the first line is corrupt, it includes the «export» command).

Re-exporting that env-variable correctly (wrap the «/d/…YYYY» with single quotes, remove the trailing «;», and remove the «export SSH_AUTH_SOCK;» part) causes ssh-agent to work properly again.