On Windows GIT_SSH environment variable not respected
Asked by Dominic P:

After a recent update, SSH with SourceTree broke on me.

On my private repos I only allow modern, secure SSH ciphers. This used to work fine, but now I get a "No matching cipher found" error anytime I try to fetch or push. It looks like the official Windows Git comes bundled with an old or crippled OpenSSH client that doesn't support modern ciphers.

For command line usage, I was able to work around this by setting the GIT_SSH variable to point to my Cygwin SSH client. But, SourceTree doesn't seem to respect this setting and still tries to use the bundled SSH client.

Any ideas on how I can work around this?


Answers:
author: Dominic P
body: Someone on GitHub found a work around for this!

It turns out there is a hard-coded cipher list in Program Files\\Git\\etc\\ssh\\ssh_config. All you have to do is comment that line and everything works again.

I still don't know how it was working before the update, but at least it's working now. We can go ahead and close this.


author: Mike Corsaro
body: Hello! Could you make sure your PATH environment variable is set to the location of your SSH agent? Sourcetree uses that setting to find the SSH agent to use.

comments: author: Dominic P
body: Hi Mike, thanks for the helpful response. I tweaked the PATH variable so the Cygwin bin directory came before the Git directory, but unfortunately, even after a restart, I'm seeing the same behavior from SourceTree.

From Windows cmd, I can type in: \`ssh git@myserver.com\` and connect with no problem. So, the environment variables are correct.

You mentioned the SSH agent. I don't think this is an issue with the agent so much as the SSH binary itself. I'm not sure what ssh client SourceTree is trying to use, but it doesn't support modern ciphers like chacha20-poly1305@openssh.com or aes256-gcm@openssh.com


author: Mike Corsaro
body: Are you using Embedded Git, or System Git? And are you using OpenSSH, or Putty? Additionally, I would try replacing "ssh-agent.exe" in the current git install with your new one.


author: Dominic P
body: Hi Mike, I've tried it with both embedded and system Git, and I get the same results with both. I'm using OpenSSH not Putty.

I replaced the ssh-agent.exe in the Git install, and nothing changed. Then, I tried replacing the ssh.exe in the Git install and I got a new error about cygwin heap mismatch. So, I have at least confirmed that SoureTree is using the ssh binary included in the Git install and not the one that comes first in the PATH environment variable.

It would be nice if SourceTree respected the GIT_SSH environment variable because I could just point it to the binary I want to use without messing with my PATH. In my case, I actually need the Git bin to come before my cygwin bin for interoperability with other apps (namely npm which has some kind of vendetta against cygwin).


author: Mike Corsaro
body: We don't often see users using a custom SSH agent, but I'll file a ticket to add support. I'd also recommend filing a ticket on the Git for Windows repo to ask and see if they're willing to upgrade the current openssh version.


author: Dominic P
body: Ok, now I'm really confused. I starting gathering version information to do what you suggested, and I discovered that the bundled OpenSSH with Git is actually newer than my cygwin version and specifically lists support (via "ssh -Q cipher") for all of the ciphers my server is offering.

But, even though it says it supports those ciphers, I get the same error about no matching cipher found if I try to use it directly from the command line.

I tested it against some other SSH servers, and it seemed to negotiate a cipher without issue. Any ideas at this point? It's almost starting to sounds like an issue with my server although it was working perfectly before the update.


author: Dominic P
body: I filed an issue for this on the Git for Windows repo here: <https://github.com/git-for-windows/git/issues/1723>


Tags: windows