Error running ssh.exe when pushing a Git repo from Visual Studio

Viewed 2807

I can push to Github using Git at the command line with no problems. Now I'm trying to use Visual Studio 2019 to push to Github. I opened the Git > Manage Branches window in Visual Studio and clicked on the Push link on my current commit. I get the following error:

Opening repositories:
C:\Users\brubin\source\repos\MyRepo
Commit 6da600da created locally in repository C:\Users\brubin\source\repos\MyRepo
Pushing master
Pushing to github.com:MyUser/MyRepo.git
Error: cannot spawn C:/WINDOWS/System32/OpenSSH/ssh.exe: No such file or directory
Error encountered while pushing to the remote repository: Git failed with a fatal error.
unable to fork

Failed to push to the remote repository. See the Output window for more details.

ssh.exe does exist at that path. I've tried running Visual Studio as administrator as well.

enter image description here

4 Answers

Change the core.sshCommand setting

Visual Studio 2019 will try the core.sshCommand setting. This defaulted to the 32-bit ssh client in C:\Windows\System32\ for me as well.

I had success changing the configuration as shown below. Open a command prompt and change the path to your ssh executable of choice - in my case it is the version from Git for Windows.

git config --global core.sshCommand "\"C:\Program Files\Git\usr\bin\ssh.exe\""

Yes, including the " and then escaped \", otherwise it will misread the setting because of the space and the error message likely reads C:\Program cannot be found or similar.

The setting can then be found in your home directory in the .gitconfig file.

I think I've managed to resolve the issue here while still using OpenSSH. Built-in Windows 10 OpenSSH is a 64-bit program. But the Git, that is running from within Visual Studio is 32-bit. Visual Studio uses the one in C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\bin" (adjust the path accordingly to your VS version).

The thing is, that Windows uses virtual folders to prevent 32-bit programs from accessing 64-bit libraries. So if 32-bit app tries to access System32 folder, it is being redirected to SysWOW64 instead. And there is no OpenSSH there. You can simulate that by trying to access OpenSSH folder from 32-bit powershell window:

> cd C:\Windows\System32\OpenSSH\

What you want to do is to set GIT_SSH to

C:\Windows\SysNative\OpenSSH\ssh.exe

SysNative is a virtual folder, it does not exist on your system physically. But by accessing it, program won't be redirected to SysWOW64

I added an environment variable GIT_SSH and set it to set c:/program files/git/usr/ssh.exe, but I still get the same error.

Note: you would have to rel-launch Visual Studio from a new CMD, making sure said CMD has inherited from the GIT_SSH environment variable.

And you need to launch it as you, not as Administrator.

github.com:MyUser/MyRepo.git is not a valid SSH URL, git@github.com:MyUser/MyRepo.git

But it can work if you have a %USERPROFILE%\.ssh\config, with a Host github.com entry, referencing User Git and an IdentityFile /path/to/private key.

Trying to get the escape sequences correct for both PowerShell and git is going to have you ripping your hair out. I STRONGLY recommend you edit %UserProfile%.gitconfig in Notepad or Vim.

In any case, the line that worked for me (Windows 10 as of 19FEB2022, Visual Studio 2022, Git for Windows but NOT using any of its internal nonsense, instead using the native Windows OpenSSH feature), was PRECISELY AND STRICTLY this EXACT byte sequence:

[core]
    sshcommand = '"C:\\Windows\\SysNative\\OpenSSH\\ssh.exe"'

EXACTLY that, and ONLY that. Note the single ticks around the quotes. I spent way too long trying to find a way to wind up with this exact sequence using all sorts of batshit escape tricks from PowerShell, so that I could deliver a nice, clean, one-line PowerShell command that would set this. I could not do so, and was kind of appalled. I don't know which to blame more, PowerShell or git, but if anybody else can deliver that, please reply.

In any case, try making the change above, EXACTLY, and then restart Visual Studio.

Related