Allow using the ssh-agent from PowerShell/Win32-OpenSSH

[chx]

There's a wonderful ssh port by ... um... Microsoft :) Could the two talk to each other please?

[fpqc]

Maybe there's a simple way by adding a unix domain socket directly to WSL init as well as creating a connection to the ssh-agent from the lxssmanager service and setting the SSH agent environment variable?

When the WSL COM interface becomes documented better, the Win32-openssh devs might be able to implement this themselves without help from the WSL team. You could even build a proof of concept now using the undocumented interface and some of the tricks used in Alex Ionescu's lxext/lxserver project.

You could even implement it now with the following (vaguely):

Take Alex Ionescu's lxserver source code and replace the guts of it with something that just forwards unix domain socket communications back and forth to the socket on the ssh-agent service. Then modify lxext's sourcecode so that it just opens a socket as usual and forwards that on to the lxserver. Then finally, set the ssh_auth_agent environment variable to the location of lxext's socket, which is by default

/tmp/lxexec-socket

At least, that's the handwavey way to do it. You could probably directly add the lxserver side of this to the ssh-agent sourcecode directly (avoiding the separate lxserver that is forwarding messages), but you still need something (at least right now) like lxext on the linux side to open up the socket and push it through the lxssmanager boundary, because to my knowledge, there is no way to tell WSL's init to open a socket for you directly, though this might be a feature added to the lxssmanager service in the future.

[lediur]

Now that the OpenSSH beta client is publicly available, is there any news around making this possible? Would love to see this use case so ssh key management gets a lot simpler across the Windows / WSL boundary.

[rupor-github]

Something like this: https://github.com/rupor-github/ssh-agent-wsl?

[fpqc]

@rupor-github yeah, but I think it could be made even more streamlined now with the WSL-windows direct socket connections added in 1803.

https://blogs.msdn.microsoft.com/commandline/2018/02/07/windowswsl-interop-with-af_unix/

[rupor-github]

You may be right - but it will require changes in openssh-portable. Also, from https://blogs.msdn.microsoft.com/commandline/2018/02/07/windowswsl-interop-with-af_unix/ :

"A WSL Unix socket can only communicate with a Win32 Unix socket OR with a WSL Unix socket, but not both. For instance, a WSL Unix socket server can only accept connections from either WSL Unix socket(s) OR Win32 Unix socket(s). So, how is it determined which one is it? It’s based on the path the socket is bound to or connecting to, as specified in the bind or connect syscall. If the Unix socket path is a DrvFS path (i.e your system volumes mounted within WSL, ex: /mnt/c, /mnt/d etc.) then it can only communicate to a Windows Unix socket. If the path is a LxFS path (i.e Linux mounted volume within WSL, ex: /home, /var, /usr etc.) then it can only communicate with WSL Unix sockets."

Not sure how "streamlined" this would be....

[Rondom]

PowerShell/Win32-OpenSSH#1024

[therealkenc]

The OP ask, at least as imagined sharing AF_UNIX interop, is combination prerequisite #5961 and the above referenced external ask PowerShell/Win32-OpenSSH#1024. There is also PowerShell/Win32-OpenSSH#1461 on the books, which would get you there. In the meantime one can set up a proxy like ssh-agent-wsl mentioned above, or maybe creative use of jstarks/npiperelay on \\.\pipe\openssh-ssh-agent might work.

Notwithstanding open #5961 there is no WSL actionable "could the two talk to each other". Porting over to discussion forum for tips/tricks.