Make SSH Agent use UNIX Domain Sockets

[Rondom]

With the latest Insider Build supporting UNIX Domain Sockets, can SSH-Agent support communication via UNIX Domain Sockets?

This would simplify porting existing applications relying on ssh-agent. Once WSL supports interaction with AF_UNIX sockets, it might even be possible to only run one SSH Agent.

https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

[manojampalam]

Since we need to support downlevel platforms, we cannot completely replace the existing named-pipes based alternative yet.

[Rondom]

Since we need to support downlevel platforms, we cannot completely replace the existing named-pipes based alternative yet.

Of course.

[WSLUser]

Any updates to this?

[manojampalam]

Related conversation in #827

[flickerfly]

I'm surprised this isn't getting more attention. It would save me hundreds to thousands of keystrokes a day entering my password for my ssh key as I can't find a stable way to implement any of the workarounds.

[davidmatson]

@manojampalam:

Since we need to support downlevel platforms, we cannot completely replace the existing named-pipes based alternative yet.

Can UNIX domain sockets be used on platforms that have them, falling back to named pipes on older platforms?

The SSH agent provided by this project is really useful - it "just works" without needing an extra password on Windows since it uses DPAPI. It would be great to be able to make use of this agent even when other features on this SSH client have problems (for example, I'm currently hitting #1684).

[WSLUser]

Windows Terminal does this for some DirectX features since Visual Studio uses it on Win7. Don't know why we can't add version checks here as well.

[davidmatson]

Or, even better than a version check, look for whether there's an afunix driver present (API equivalent of checking sc.exe query afunix [State == RUNNING]).

[WSLUser]

I guess it would depend on what provides a faster response.

[davidmatson]

I would just caution against using a OS version check. For example, some internal/test versions do not have afunix present even with a current OS version number.

[jamiehankins]

Since we need to support downlevel platforms, we cannot completely replace the existing named-pipes based alternative yet.

You could look at the path and set behavior based on whether it's a pipe or not.

[jamiehankins]

Is there any chance at all of this going anywhere?

[JojOatXGME]

Hi, I just found this issue and there are a few topics I thought might be good to clarify. (If I am wrong about something, I am happy to hear it. This is just based on my knowledge after researching the topic over the weekend.)

This would simplify porting existing applications relying on ssh-agent.

Which ssh-agent is meant here? wsl-ssh-pageant is one of the very few agents I can think of, and it was specifically developed for WSL. I am not aware of a lot of applications using the native AF_UNIX support on Windows. Note that ssh and ssh-agent of Git for Windows are not using native AF_UNIX support. They existed long before Windows introduced it. Git for Windows is instead using the compatibility layer provided by Cygwin.

Once WSL supports interaction with AF_UNIX sockets, it might even be possible to only run one SSH Agent.

I think the topic of supporting AF_UNIX in WSL2 is tracked by microsoft/WSL#5961. It doesn't look like it is making much progress. I also just created microsoft/WSL#11207 for specifically supporting forwarding the ssh-agent into WSL. (I assume this would be much easier to implement.)

I feel like resolving this issue does not actually provide much value as long as neither WSL2 nor Cygwin support native Unix domain sockets. I couldn't find any discussion about supporting native Unix domain sockets in Cygwin. I am wondering if there are specific issues with the AF_UNIX implementation of Windows that prevents Cygwin from supporting it. If all applications started to support one common backend (like AF_UNIX), it would be the best solution, of course. However, I think WSL2 and Cygwin have to move first, as we cannot easily work around their limitations. For the missing support in this SSH Agent, there are already solutions like wsl-ssh-pageant.

FYI, the incompatibility between the SSH Agent of Windows and Cygwin would be much less problematic if they would not conflict by using the same environment variable. Maybe this project could introduce a new environment variable named MS_SSH_AUTH_SOCK or SSH_AUTH_PIPE which takes precedence over SSH_AUTH_SOCK?