'Mingw-w64: ssh-add works until git fetch (Error connecting to agent: Bad file descriptor)

I'm on windows/Git bash/MingW64, trying to automate adding ssh keys for use with git. I've followed this guide, altering only the path of my private key file. It seems to work - when opening git bash I get "succeeded Identity added: /c/users/...".

ssh-add -l also shows that my key was added properly, and the port seems to be configured.

Btw - At this point $SSH_AGENT_PID matches the process in ps and $SSH_AUTH_PORT seems valid (/tmp/ssh-cEU4wbNe3vo4/agent.927 or similar)

But when I cd into my git repo and run git fetch I get:

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

After that, ssh-add no longer works, printing:

Error connecting to agent: Bad file descriptor

Which is strange because both $SSH_AUTH_PORT and $SSH_AGENT_PID Did not change at this point, and I've tried exporting them just to be sure.

Starting a new SSH-AGENT and adding my key works in the same terminal session, but trying git fetch again will have the same effect.

What is git doing that's messing with the SSH agent?



Solution 1:[1]

I am working under Msys2, with ConEmu. I have recently faced a couple of instances of message Error connecting to agent: Bad file descriptor. After reading this post, I recall trying git pull shortly before the error appeared, so it might have triggered the error. I didn't take the time to test systematically to confirm.

As per Reuse in PowerShell a running PuTTY agent (pageant), I checked whether the problem was only with specific combinations agent-client.

enter image description here

Given WinSCP was working fine (A1-C2 ok), and Msys2 bash ssh was not (A1-C3 not ok), I confirmed the problem was with Msys2 bash ssh-pageant (A1-P1-C3 broken), even though the same checks as you showed did not suggest any problem.

$ env | grep SSH
SSH_AUTH_SOCK=/tmp/.ssh-pageant-RY16205
SSH_PAGEANT_PID=1615
$ ps
      PID    PPID    PGID     WINPID   TTY    STIME COMMAND
     1618       1    1618      16144  cons0   Jan 25 /usr/bin/bash
     1615       1    1615      15960  ?       Jan 25 /usr/bin/ssh-pageant

Since the problem was with ssh-pageant, I simply restarted it with

  1. Killing the existing ssh-pageant

     $ /usr/bin/ssh-pageant -k
    

Note that if, for whatever reason the running ssh-pageant is not killed with this command, you can always do that from the Task manager.

  1. Launch again ssh-pageant and set appropriate environment variables

     $ eval $(/usr/bin/ssh-pageant -r -a "/tmp/.ssh-pageant-$USERNAME")
    

or

    $ /usr/bin/ssh-pageant -r -a "/tmp/.ssh-pageant-$USERNAME"
    SSH_AUTH_SOCK='/tmp/.ssh-pageant-RY16205'; export SSH_AUTH_SOCK;
    SSH_PAGEANT_PID=10014; export SSH_PAGEANT_PID;
    echo ssh-pageant pid 10014;
    $ SSH_AUTH_SOCK='/tmp/.ssh-pageant-RY16205'; export SSH_AUTH_SOCK;
    $ SSH_PAGEANT_PID=10014

and it works fine. Since I did not test thoroughly, I might face the problem again after a new git pull.

Note that I use git under Msys2 bash, I don't have a separate git with its own ssh. So the permanent solution posted in an answer does not seem to apply for me. I don't seem to have Windows OpenSSH either, so this would not apply for me either. I still have to find the root cause for my problem.

Related:

  1. https://community.atlassian.com/t5/Sourcetree-questions/ssh-add-l-returning-quot-Error-connecting-to-agent-Bad-file/qaq-p/1654077
  2. https://github.com/cmderdev/cmder/issues/1781

Solution 2:[2]

Finally after a long search I found it. The Windows update broke my setup ?, specifically Openssh. I have to enter my passphrase every time since last windows update, and given that your question is fairly recent I suspect the same is true for you.

I think Win32-OpenSSH#1693 is related.

In my ~/.gitconfig in [core] there was a line (I don't remember what issue exaclty I had earlier)

   sshCommand = C:/Windows/System32/OpenSSH/ssh.exe

Removing it gave this error

error: cannot spawn C:/Windows/System32/OpenSSH/ssh3.exe: No such file or directory
error: cannot spawn C:/Windows/System32/OpenSSH/ssh3.exe: No such file or directory
fatal: unable to fork

However, replacing it with

    sshCommand = "C:/Program\\ Files/Git/usr/bin/ssh.exe"

made everything work as I expect.

I think Error connecting to agent: Bad file descriptor means something is crashing under the hood, and given that it's since recently, most likely due to the Openssl update.

P.S. You can check if your OpenSSL was updated by checking the "Date modified" of files in C:\Windows\System32\OpenSSH. For me that was very recent and aligns with the moment the ssh-agent stopped functioning.

Solution 3:[3]

Try first to simplify your %PATH% before launching git bash and your SSH command.

In a new CMD, for testing:

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%GH%\mingw64\libexec\git-core;%PATH%

Make sure your environment variables don't have a GIT_SSH(_xxx) defined.
Type in that same CMD (before launching the bash)

set GIT

Then check if the issue persists.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 JBSnorro
Solution 3 VonC