Support MSYS2 ssh-agent sockets on Windows

[wheybags]

Summary

Support using ssh keys from msys installations, like the one which ships with git, or anything else which can connect to an ssh-agent socket.

Context

I use ssh and git on windows through the copy of msys that ships with git (git bash). I can start an ssh-agent there, or I can set the SSH_AUTH_SOCKET environment variable. When I used keeagent, I could set a socket location in keeagent settings, and it would run an ssh agent that I could point at in git bash. I can't currently (to the best of my knowledge) use keepassxc's ssh agent functionality from git bash.

I can see two methods of implementing this:

• Do what keeagent does, and implement an ssh agent server which can be accessed through a configurable path. This is preferable to me, as it is the easiest to set up automatically on login (just put an export SSH_AUTH_SOCKET=blah line in my .bashrc, and configure the same path in keepassxc)
• Allow keepassxc to use some configurable path to a socket file on windows like it does on linux/osx. AFAIK, on linux/osx keepassxc will add its keys to an agent that it connects to via a file specified by the SSH_AUTH_SOCKET environment variable. A similar method could be used on windows, either through the same standard environment variable, or by some config setting. This would require the user to work somemagic to ensure the environment variable was set before starting keepassxc, but is more in line with standard practice on other systems.

Apologies if this is a duplicate issue, I did try searching older issues, but I didn't find anything.

[droidmonkey]

Will be in the next release: https://github.com/keepassxreboot/keepassxc/pull/3801

[wheybags]

Ah great, thanks!

[hifi]

Overriding the socket is only supported on non-Windows platforms in develop at this point.

Does MSYS2 use a named pipe like OpenSSH for Windows does?

[hifi]

Did a quick look. Cygwin/MSYS2 sockets are an authentication hack with a temporary text file and a loopback TCP socket.

I'm not really sure if this is in the scope of KeePassXC. An external agent multiplexer that ties together Pageant, OpenSSH for Windows and Cygwin/MSYS2 is probably a better solution here.

You can likely make MSYS2 git use plink.exe (from PuTTY) and use Pageant to connect to git repositories over SSH.

I'll keep this issue open for now if it ends up making sense to add Cygwin/MSYS2 socket support.

[Okeanos]

As a workaround you can use the Windows 10 OpenSSH agent introduced sometime before version 1803. This involves messing with Git Bash a little, though, and has to be (partially) redone each time you update Git Bash.

• Install Git Bash & KeePassXC normally
• enable the OpenSSH Agent in Windows via the Services management interface by setting the OpenSSH Authentication Agent to automatic and starting it.
• (optionally?) set a User Environment Variables for SSH like GIT_SSH : %SystemRoot%\System32\OpenSSH\ssh.exe

Now delete stuff from Git Bash (note that you should NOT delete %ProgramFiles%\Git\usr\bin\ssh-copy-id, though, as there is no Windows supplied alternative):

%ProgramFiles%\Git\usr\bin\ssh-add.exe
%ProgramFiles%\Git\usr\bin\ssh-agent.exe
%ProgramFiles%\Git\usr\bin\ssh-keygen.exe
%ProgramFiles%\Git\usr\bin\ssh-keyscan.exe
%ProgramFiles%\Git\usr\bin\ssh-pageant.exe
%ProgramFiles%\Git\usr\bin\ssh.exe
%ProgramFiles%\Git\usr\bin\sshd.exe

There are a couple of additional issues with this workaround beyond the "repeat after update"-thing, though, as Windows 10 OpenSSH is seriously outdated (PowerShell/Win32-OpenSSH/issues/1693) and suffers from things you may or may not experience due to that such as PowerShell/Win32-OpenSSH/issues/1322, PowerShell/Win32-OpenSSH/issues/1172, PowerShell/Win32-OpenSSH/issues/1515. Additionally, if you do (not) decide to remove the Git Bash bundled SSH binaries, some unrelated tooling may break (see git-for-windows/git/issues/1683).

For me personally it was kind of fine to be honest regardless of the linked issues 🤷‍♂️ .

[Okeanos]

Git for Windows 2.33.0 was recently released that allows selecting an arbitrary non-bundled SSH version, e.g. the Win32 one shipped by Windows 10.

With that in place, using KeePassXC as a source of SSH Keys for Git for Windows becomes trivial. Imho that is a workaround close enough to a fix to this issue.

[Okeanos]

Somewhat related to this issue I stumbled across Win32-OpenSSH#1761 – there are ideas to support Unix SSH_AUTH_SOCK compatible output from Windows OpenSSH. This may be another workaround/alternative solution to the Git For Windows + ssh-agent socket problem in the future.

[Okeanos]

Even though I am loath to bump this again: KeePass + KeeAgent offer a SSH Agent solution that can replace both the Windows OpenSSH Agent as well as the Git-Bash OpenSSH Agent and provide SSH keys to both at the same time.

How is this different from just using the Windows OpenSSH Agent in Git-Bash (and everywhere else) you might ask? Well, Windows OpenSSH has some very uncomfortable bugs (such as this one, still occurs even though it says fixed) that render is unusable/unreliable in a lot of cases. That means using KeePassXC with SSH on Windows becomes unreliable and as a result I have to retract my previous statement that using Windows OpenSSH is a "workaround close enough to a fix".

Personally, I like KeePassXC way better than plain KeePass, particularly because of the way superior Browser integration and technically the native SSH support (Putty is not an option for me personally), but not having reliable SSH is a huge problem for me. Is there any way that some of the magic happening in KeeAgent (that offers support for Pseudo-Linux-Sockets along with Windows Named Pipes) can be replicated here? Is there something that can be done to facilitate that beyond providing an implementation as PR?

Edit: There's also the wsl-agent-bridge that apparently transforms the Windows OpenSSH output into a (WSL compatible) Pseudo-Linux-Socket. As well as wsl-ssh-pageant which also does apparently do something similar.

[Okeanos]

There exists an open PR for Windows OpenSSH to support the previously mentioned Unix sockets. Let's see how that plays out.

I also recently stumbled across OmniSSHAgent that may be of interest here.