Support GPG and smartcard users #827
Comments
|
As of now, we don't support this scenario. This will be added to our backlog and will be picked based on the priority. |
|
Is gpg-agent listening on a network socket? |
|
@manojampalam yes, the gpg-agent creates |
manojampalam
changed the title
|
@vovcacik your understanding is correct. On Windows the logical equivalent of Unix Domain Sockets is named pipes (that inherently provides authorization capabilities). We unfortunately have no alternative way to use smartcards with this version of OpenSSH. Its a feature that we need to implement for Windows. |
|
Given that UNIX domain sockets are pretty similar to Windows named pipes, I wonder if it'd be possible to create a program that sets up a named pipe that gets assigned to
|
|
My |
|
@vovcacik what version of GPG do you have installed, and is it a Cygwin or MSYS build? They each have their own format for the sock file (or more than one possible format), all of which would need to be supported. |
|
@coldacid it is neither Cygwin-based, MSYS-based nor Gpg4win, but rather official native build. |
|
@vovcacik Gpg4win uses the "official native build" as you put it. Could you update to 2.2.3 and see what the socket file looks like afterwards? |
|
Protocol used by Windows version of ssh-agent is the same as in Unix. So a named pipe to network sock interop adapter should work for your case. |
|
@manojampalam excellent. I'll take some time this weekend to prototype one out. |
|
I whipped up a quick program that should provide a named pipe connected to gpg-agent but it unfortunately doesn't work. I'm not too good with low-level socket/stream stuff so perhaps someone else can figure out what I'm doing wrong for the actual communication between the pipe and the TCP socket served by gpg-agent. I've put up the program as a gist: https://gist.github.com/coldacid/6e4e8306bcdc0a8954961454bc2558ee |
|
Also it looks like [Edit] note to self: described at #669 (comment) |
|
I've filed a feature request with GnuPG to support named pipes for ssh-agent on their side: https://dev.gnupg.org/T3883 |
|
Just to make sure this is linked here, as it might be interesting context... https://lists.gnupg.org/pipermail/gnupg-devel/2017-April/032825.html Wish you luck! |
|
It sounds like Werner doesn't want to accept named pipes, but Win32-OpenSSH switching away from them doesn't sound like it'll happen either. Shame that Windows didn't have AF_UNIX sockets from the get-go. I wonder if it'd be feasible to turn on AF_UNIX support in the ssh client now that it's available since build 17063, and get it enabled in Windows builds of gpg-agent as well. If that could be done without changing/removing existing functionality in both systems, and without requiring users to be on the cutting edge builds of Win10, then it might be a way around this impasse. |
|
@coldacid your adapter in here |
|
@manojampalam I tried async as well, without any change in results. I just never updated the gist with it. |
|
@coldacid got an initial (oversimplified) version posted here https://github.com/manojampalam/ssh-agent-adapter The IO redirection part works just fine. What's still needed is the logic to read port and cookie from the authentication file. I've put in TODO's in uds-2-np.c indicating the places this logic needs to go to. |
|
@manojampalam I can certainly take a look at the port and cookie stuff this evening. |
|
@manojampalam I started work this evening to parse out the port and cookie info, but my C is pretty rusty and I still need to get the "socket" file name to pass to my new function. Tomorrow evening I'll continue on and see if I can't get all this to work. By the way, with a deeper dive into gpg-agent, I found that it's not relying on Cygwin or MSYS at all, but rather its own libassuan library to provide the AF_UNIX emulation. This explains the confusion around different possible socket file formats; a Cygwin build would have libassuan think that AF_UNIX sockets are available (and use Cygwin's emulation), an MSYS build could go either way based on environment configuration at build time, and the official Gpg4win builds use libassuan's own emulation. Because of this I considered pulling in libassuan, but figured the cost/benefit ratio was better just writing my own function for this. |
|
I've PR'd some work to parse out the port and cookie from the socket file and to send it across to gpg-agent, but uds-2-np seems to be getting stuck same as my gisted C# program even with my changes. |
|
@manojampalam have you had a chance to look at the work I PR'd to ssh-agent-adapter yet? Perhaps there's something I've overlooked that will make it work. |
|
Not yet @coldacid. Were you able to debug where its getting stuck? Was there any traffic in and out the adapter? Can you point me to instructions to install and use gpg-agent on Windows? |
|
Hello! Seems like i am doing something wrong, because i cannot make it to work for me. And it still does not work. What i am doing wrong? Help me please! |
I tried setting this up on another PC and had exactly the same issue. I’m going to take a look at my configuration on the working one and see if I can identify any missing steps. |
|
Two thoughts, first, the pipe path should have two slashes at the front, so Second, maybe check the ssh client version as well? I have been using the latest from github which is often much newer than is available directly through Windows. |
|
Ah yes, per the second point, I uninstalled the bundled OpenSSH from Additional Features in Settings and installed PowerShell/Win32-OpenSSH. This then worked perfectly. (The most recent MSI installer from the releases section did the trick.) For my case, I guess this beta version should work fine, otherwise it might be worth searching through updates from Windows Update as I believe newer versions of the SSH client might be released there. EDIT: This was on the second system, where I had already done the configuration outlined in my earlier comment - which I would expect you'd have to do regardless. On the first system, I don't recall ever installing this but it is kept very up-to-date either way, I think I happened to have a more up-to-date build of the SSH client which is why that system worked. |
|
I have removed openssh client optional feature in Windows and then installed openssh from github releases. Here are several outputs that may tell something. And there are my config files: sshcontrol file contains the ID of my keygrip. With wsl-ssh-pageant all worked but i have decided to get rid of intermediate program and use new features of gpg4win and openssh and now it is not working. |
I'm having the exact same problem. All the way down to the output and config files. I still have no idea what I'm doing wrong. |
|
@Anon-4 I'm not affiliated with the project, just another user. I was able to Windows 11 working with no extra software other than openssh provided with Windows 11 and gpg4win/Kleopatra. Windows 10 didn't go as smoothly because the \.\pipe\ pipe/socket was not created without some coercion. For that I needed wsl-ssh-pageant and to run it on login (via shell:startup) using the following arguments In each case (Windows 10, Windows 11) I observed that some gpg process must first run to initialize the agent. Starting Kleopatra at startup (to run in the system tray) seems to be enough. Happy to compare configs and outcomes with you if helps get you going. |
|
Hey @thxkiwi! Thanks for your help on this. I forgot to mention that I'm on Windows 11 in my previous comment - although I'm thinking it won't make a difference. I looked a bit further into it and it looks like I am running into an issue with the pipe creation - just like your windows 10 case. I turned on logging for the gpg-agent and I got this: Running the I have tried maually setting the Although, if I run This is what confuses me. Do you think I have some sort of permission problem? Here are my configs and other metadata:gpg-agent.conf: Versions: Thanks for you help again! |
|
@Anon-4 (also not affiliated with project, just a user interested in getting this working repeatably and consistently) I have a working system I can compare things to, I have a non-working system I was attempting to set up at one point but no longer need and it's not very convenient to access but could access if need be. Edit: both systems are Windows 11, but unless the problem actually appears to be from OpenSSH's end, I suspect whether the system is Windows 10 or 11 doesn't matter, and one can update OpenSSH manually if need be either way. |
|
@Anon-4 [Preface: I am not a "Windows developer" so help me help you] I'll turn on logging for gpg-agent and we can compare. What are you doing to enable gpg-agent logging? I've tried using log-file in gpg-agent.conf and got nothing. I've turned on logging via Kleopatra and only get gpg log messages. UPDATE: Adding software versions gpg (GnuPG) 2.4.0
libgcrypt 1.10.1
Copyright (C) 2021 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: C:\Users\User\AppData\Roaming\gnupg
Supported algorithms:
Pubkey: RSA (1), ELG (16), DSA (17), ECDH (18), ECDSA (19), EDDSA (22)
Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7),
AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11),
CAMELLIA192 (S12), CAMELLIA256 (S13)
Hash: SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10),
SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)
PS C:\Users\User\AppData\Roaming\gnupg> ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
Are you running Windows 11 22H2? I'm still on 21H2 just FWIW. |
|
I followed the thread and was able to get a SSH session to login using the yubikey. Interestingly it only works once.. after you logout of the SSH session and try again it does not work a second time. You need to redo the whole procedure or --> I noticed you can get it to work without having to stop and restart gpg-agent.exe --homedir... - by just entering gpg-connect-agent /bye TWICE in a non-elevated user powershell session.. I would really like to be able to automate the whole procedure in a task or preferably just have it work without any user/script interaction.. but i suppose that's the point of it being a dev release.. |
|
Hey all! Thanks so much for your help on this! @SamJakob To my knowledge, I'm not aware of any out-of-the-ordinary file permissions concerning anything @thxkiwi Same I came from Mac/Linux HAHAHA so that's why this thing is so confusing to me. Maybe you forgot to add the @while0x1 That is pretty Interesting though. I've tried entering |
|
@Anon-4 I was referring to the Local/gnupg folder - I’m wondering if it’s maybe some discrepancy between accounts made with a microsoft account vs a local account as that’s the only difference I can think of… |
|
@SamJakob Oh yeah that's my bad HAHAHA I doubled check |
|
@SamJakob I made a local account and it seems to be the exact same result :( Here's the log from my test account: |
|
I know you said you removed the windows version of OpenSSH but try running: Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'I found on my system that Once removing this for sure I went from having the exact same problem ( Some more details: I noticed when running If I ran gpg-agent manually in an elevated shell ssh appeared to work properly in an elevated shell as well. In a non-elevated shell ssh only worked every other time. After removing the builtin ssh client and restarting, the pipe isn't getting created on login and instead is only created when the gpg agent runs via something like |
|
Coming back to this on a Windows 11 22H2 machine, I now get what others have been experiencing "invalid format" resulting from ssh-add -L when using I observe, similarly to @kaylynb , the I observe that UPDATE I've tried using what previously worked for me in #827 (comment) but now get |
My Windows 11 22H2 Issues ResolvedSoftware Installed
gpg.confNone gpg-agent.confsshcontrolCreated using the output from Copy and paste the key grip of the authentication key into the file. Include a newline after the 40-byte key grip ID. Running gpg-agent
Errors and How I Resolved Themaccess denied
invalid format
agent refused operation
|
My Issues ResolvedDISABLE the openssh ssh-agent Windows service IS IMPORTANT @cyrmax @Anon-4 @SamJakob Have you slove this problem ? I have met the same problem, get There is my env below: Windows 1122H2 22621.1413 GPGgpg-agent.confOpenSSHOpenSSH_for_Windows_9.2p1, LibreSSL 3.6.1 |
If you're still not seeing any keys output from |
|
@thxkiwi Thanks your help! I got logs below: Do you know what does it mean? |
|
I think "5" relates to a Windows HRESULT "ERROR_ACCESS_DENIED". I saw that error when I was running gpg-agent with elevated privileges. Are you running gpg-agent with elevated privileges, or as administrator? |
|
I just install gpg4win from their offical website, and open the Kleopatra in Desktop icon, and never see any prompt for elevating privilege. |
|
Eh, I think I met a other question. My Environment:Windows 11 22H2 (OS 22621.1702)gpg-agent run as Administrator gpg.confgpg-agent.confkeygrip from |
I would see that error if I was running gpg-agent or gpg-connect-agent elevated. |
Does the pipe exist?
Have you checked the logs for any errors?
Is this file formatted correctly? I found sshcontrol to be quite finicky. Check the file contents against the documented format for sshcontrol (https://www.gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html) |
Thanks for this, I stopped the service and it fixed my issues :) It was also set to "Automatic" startup for some reason so I disabled it. |
|
I want to add that if you encounter the issue |
|
I followed the guide, but I get after setting $env:SSH_AUTH_SOCK="\.\pipe\openssh-ssh-agent" |
Yes, all you need is DISABLE the openssh ssh-agent Windows service. |
and others
It seems like
ssh.execannot usegpg-agent.exesince the latter is storing socket info inS.gpg-agent.sshfile and you expect it to be named pipe.Are there any guidelines how to use
ssh.exeand my authentication GPG key stored on smartcard?EDITS:
https://dev.gnupg.org/T3883
The text was updated successfully, but these errors were encountered: