Fail to RemoteForward a unix domain socket #1564
Comments
|
Well at a first step, try upgrading to 8.1 and attempt to reproduce the issue. Submit updated logs if it still appears. |
|
Turns out even OpenSSH for Windows supports UDS, it's still not enough. Because GnuPG on windows does not use UDS at all. The file is a simulated UDS. For those who wants to forward gpg agent like me, I wrote a tool that built a bridge between GnuPG and openssh. It has been working fine for a month now. |
|
I just got the same problem. I managed to get the path working, but it fails with the same error as OP. This is using v8.1 on Windows 10 Pro (1909). Remote forward is set up like this in the config: when trying to run |
|
@BusyJay , can you share your steps for this solution |
|
You mean how does the tool work around the problem? The simulated socket used by gnupg stores the port of its http service. So the tool just read the port and build a local http redirect service bridging between gnupg and ssh. The steps about how to use the tool is written in README: https://github.com/BusyJay/gpg-bridge. |
|
I'm so close in using Yubikey+gpg to admin linux servers over windows' built in openssh client! This agent forwarding is the only missing bit so that I can forward my gpg agent (and yubikey) to jump hosts to be able to manage other linux hosts. Microsoft: Please fix this issue ❤️ |
|
Running into the same issue. +1 |
|
Few months later and I too got the same issue here, with the same conditions and the same setup. OpenSSH version: Regarding this:
you could just change the |
|
I did the same hack to escape @nezorflame suggested and it seems that the agent is connected. Also checking if the agent could be reconnected after SSH connection has been established is successful (as suggested here): Also what @PeterStaev posted as being a problem also seems successful (at least to me): However, when I try to sign something, pinentry-qt doesn't pop up on my local box, but bails out with missing ioctl device. I know that one solution is to att |
|
Hey, would just like to bump this as Google is leading me here in my searches. I have git-bash installed too (Not in WSL, just on Windows itself) which ships with OpenSSH 8.4. Using either a For my use case, all I really wanted was working forwarding within VS Code Remote, so I changed I'm still confused as to why it would work on the the basic OpenSSH implementation and not OpenSSH For Windows? Are they not the same, at least in regards to how forwarding is handled? My versions: PS C:\> ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
PS C:\Program Files\Git\usr\bin> .\ssh -V
OpenSSH_8.4p1, OpenSSL 1.1.1h 22 Sep 2020 |
|
Is there any update on this? I did some mix and match with Git for Windows's SSH and GPG1, with Win32-OpenSSH and Gpg4win1. Only Git for Windows bundle works, any other combination fails. In the process I also noticed that Footnotes |
This enables socket forwarding with gpg and WSL. This is the only way to make it work in Windows, see: PowerShell/Win32-OpenSSH#1564
|
I got this to work in WSL2, and I believe I have a clue of what is happening and why this does not work on Windows. This might explain why some people have been able to make it work with git ssh, it is probably emulating Unix sockets somehow, or even using the new and now available AF Unix Socket support. So, how do you get it to work with WSL2? I'm using wsl-relay: https://github.com/Lexicality/wsl-relay All I need to do is (in WSL): socat UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent.extra,fork, EXEC:'wsl-relay.exe --input-closes --pipe-closes --gpg=S.gpg-agent.extra',noforkAnd in the ssh config file (in WSL): And it works. |
|
WSL/WSL2 is not the issue. We want it to be supported in the native Windows OpenSSH client 🙂 |
I'm not saying WSL2 is the issue, I'm just explaining the mechanism of why it does not work. It might help someone find a workaround until Microsoft fixes it. |
|
In the context of GPG agent forwarding, I suggest checking out win-gpg-agent which bridges the lack of this feature, and also do note that upstream GnuPG has picked up Windows named pipe support and it's going into GnuPG 2.3.9 and gpg4win 4.0.5. So if you're looking for this feature to get GPG working, it might be worth to just wait it out. |
|
@maertendMSFT The harder part of the problem has been solved now. Could some resources be put to handling the forward of unix sockets to named pipes? IIUC Windows devs still need an external tool that ties the knot on connecting the unix socket (already known to Windows and OpenSSH) to the named pipe gpg-agent is listening on. Either OpenSSH internalizes this, or external tools need to bridge the gap. |
Thanks, @MathiasMagnus, that worked, now I don't need |
"OpenSSH for Windows" version
7.7.2.1
Server OperatingSystem
Linux
Client OperatingSystem
Windows 10 Pro
What is failing
I'm trying to forward my local gpg-agent to remote server. Same configuration works fine when both ends are Linux. When trying to forward from Windows to Linux, it doesn't work anymore.
There are three kind of errors.
When using configuration
RemoteForward /run/user/1000/gnupg/S.gpg-agent ~/AppData/Roaming/gnupg/S.gpg-agent.extra, client reports forward success, but it won't work when actually testing it.I suspect it's because
CreateFileWcan't expand charater~to home directory.When configuring using
RemoteForward /run/user/1000/gnupg/S.gpg-agent C:/Users/me/AppData/Roaming/gnupg/S.gpg-agent.extra, client reports parse error:Bad forwarding specification.I guess configuration parser just can't stand
:.When configuring using
RemoteForward /run/user/1000/gnupg/S.gpg-agent /Users/me/AppData/Roaming/gnupg/S.gpg-agent.extra, and execute in disk C, client finally build up the channel successfully, but fails when handling connection.That's because
w32_getsockoptrejects work on a unix domain socket, it seems like a bug.I guess there is no way to get around this now. Any suggestions?
Expected output
gpg-agent is forwarded successfully.
Actual output
It fails.
Editted:
For those who wants to forward gpg agent like me, I wrote a tool that built a bridge between GnuPG and openssh.
The text was updated successfully, but these errors were encountered: