GPG yubikey socket not working
plttn opened this issue · 16 comments
SSH seems to be working, and accessing my Yubikey was working previously, but WSL2 (on two different systems) no longer is able to talk to my Yubikey.
socat
is running, but the result of gpg --card-status
is:
gpg: error getting version from 'scdaemon': No SmartCard daemon
gpg: OpenPGP card not available: No SmartCard daemon
Check these two possible failure options:
- Did you check that both socat processes are running?
- Sometimes the gpg agent within linux is started and has ownership of
~/.gnupg/S.gpg-agent
. Try to remove it and restart the WSL2.
Both socat processes are definitely running.
After removing S.gpg-agent
and doing a wsl --shutdown
from Windows, the first gpg --card-status
complains about not having an agent running
gpg: can't connect to the agent: End of file
gpg: OpenPGP card not available: No agent running
the second run results in the error message from my original post.
Maybe we can dig into the problem with a few more questions:
- Did you install Pgp4win or anything else?
- Did you check, that
gpg --card-status
run fine on windows (powershell or cmd)? - Did you import your public key
gpg -k
with trustlevelultimate
in wsl2?
Using pgp4win, gpg --card-status
working fine on Windows, I had previously imported the key into wsl2 using gpg --card-edit fetch
and set the trustlevel to ultimate yes.
Ok, one idea, can you check the version of pgp4win and pgp in wsl2?
My is actual:
- WSL:
$ gpg --version
gpg (GnuPG) 2.2.20
libgcrypt 1.8.6
- Win:
PS C:\Users\MarcKohlbau> gpg --version
gpg (GnuPG) 2.2.21
libgcrypt 1.8.6
If this doesn't help, can you build a new minimal wsl instance, export ( wsl --export
) and upload it?
Maybe we can find the bug.
The hint that no agent is available could mean gpg is not connecting against the correct S.gpg-agent
socket. Therefore it is most likely launching an linux gpg-agent in the background. Please have a look if your distribution/config uses another location for the S.gpg-agent
socket.
WSL:
»»»» gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5
Win:
PS C:\Users\Jack Platten> gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5
Ubuntu 20.04 appears to be generating S.gpg-agent
in the correct location given. Interestingly enough, if I remove all the socket files, let my config.fish
create the forwarded agent socket file, then do a gpg
action that would touch the socket, it first fails, then starts a new socket on the same file, resulting in
I'm currently going to try with a different distro and use bash to see if it's an issue with 20.04 versus a environment issue. Part of me suspects this might be an issue with Ubuntu 20.04, as it was working fine until it wasn't on both machines, and I believe I updated to 20.04 on both.
Currently testing a Debian bare minimal distro, the socket gets created by wsl2-ssh-pageant, but then gpg creates another socket to S.gpg-agent
, so card-status still complains about not having a scdaemon.
Uploading the distro now.
I've checked on another laptop if it's working on a more default setup. Maybe it's something with fish? Maybe it's escaping some of the socat command different? I've never used fish myself.
I'm using:
tobias@DESKTOP-A2ON533:~/.gnupg$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
tobias@DESKTOP-A2ON533:~/.gnupg$ gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 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: /home/tobias/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
C:\Users\tobia>gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 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/tobia/AppData/Roaming/gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
I've installed fish and tried to use the settings from the README.md and gpg is still working.
Turns out I was the idiot here, not anything to do with Windows or WSL. I changed my gnupg path on windows to be .gnupg instead of %appdata%/gnupg, and the code is only checking %appdata%/gnupg.
It wasn't until I saw @tobiaskohlbau's version printout that I realized the change was probably the issue, reset it, everything working fine now.
Thanks!
Great that we were able to help you.
Would you think and option to set the gnupg folder on windows would help? A quick check did not result in an simple way to get the the gnupg folder. An possible option would be to launch gpg --version
and extract the line Home: C:/Users/tobia/AppData/Roaming/gnupg
, but I would assume a flag should be sufficient, too.
Would checking the status of the environment variable GNUPGHOME
get closer to ruling out all the edge cases? If that's unset, it's likely the default path is being used, and if it is set, the gpg configuration folder is probably where the variable is pointing.
Just another interesting implementation side effect, you can only socket this into one WSL distro at a time.
Regarding availability only for a single WSL distro at a time: It looks like Microsoft is only using pid namespaces to isolate the distributions from each other the network namespace is shared between the instances. Therefore our launch script (for e.g. in .bashrc) thinks an instance is already running and does not launch another instance.
The following check if the auth socket is still present must be hardened against this case.
ss -a | grep -q $SSH_AUTH_SOCK
I thought about using GNUPGHOME and noticed it's also possible to configure via config file in addition to the environment variable. I could imagine that most people would prefer to change the setting via config file instead of polluting their environment variables. Did you use GNUGPGHOME or the config file?
I used GNUPGHOME
rather than the config file. To me it seems a bit odd to have a config file sitting in one place that only serves to point the data location somewhere else.