Background

I use GPG for encrypting various things locally on my machines. Things like .authinfo.gpg which gets sourced by Emacs and things like that. In past I’ve used it even more when I was actively using Password Store as my password manager. But not to go too much into off-topic, let’s talk about the issue that’s been plaguing me ever since Fedora 33 and how I, finally, solved it.

My GPG keys are saved on Yubikey (2 copies) which acts as a smart card. Once I import the key into my machine, in order to use it, Yubikey has to be plugged in (private key on the machine is just the referrence to the smart card location). Due to keys being on two Yubikeys, there’s a small gymnastic that has to be done if I plug in second Yubikey into the machine that already used the first one, but that topic is beyond the scope of this article, and will likely find a place of its own on this blog.

Fedora 34 (and I’m quite convinced 33) ships with PCSC Daemon pre-installed, and it has certain conflicts with CCID functionality of the scdaemon which is started by the GPG Agent. The issue I would have is that Yubikey would not be shown as a smart card and GPG keys would not be available. Error I got was:

gpg2 --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

While, if I restarted the pcscd.service, issue was sometimes fixed, and sometimes I just had to restart the pcscd.service again.

Fixing the issue

It would appear that the issue was in fact caused by combination of things. First thing being the fact that scdaemon has the built-in ccid compliant reader support and that might cause race-condition and the second one being the fact that in order to use pcsc library, scdaemon had to find it in the shared library location.

First I configured the scdaemon within gpg-agent by adding ~/.gnupg/scdaemon.conf with following contents:

disable-ccid

This disabled integrated support for ccid compliant readers. In addition to that I’ve added symlink in /usr/lib64/ like so:

sudo ln -s /usr/lib64/libpcsclite.so.1 /usr/lib64/libpcsclite.so

Symlink was required for the simple fact that scdaemon will search for libpcsclite.so and that doesn’t exist on Fedora, instead, they just ship libpcsclite.so.1 symlink which points to the exact minor version of the library. Pointer for this was found in the scdaemon (1) manpage:

     --pcsc-driver library
          Use  library  to  access  the  smartcard  reader.   The
          current default is  ‘libpcsclite.so’.  Instead of using
          this option you  might also want to  install a symbolic
          link   to   the   default    file   name   (e.g.   from
          ‘libpcsclite.so.1’).

Once that was done, scdaemon had to be restarted. As sending hangup signal to the process did not work for me, I just kileld it and reloaded GPG Agent to start it back up again:

pkill -9 scdaemon
gpg-connect-agent reloadagent /bye

Conclusion

Why did it take so long to fix this issue? I don’t know. I never really focused on solving it and properly testing the solution, as restart of the pcscd.service usually fixed the issue for me, and I was always pulled away by some more important work.

Do I wish this all worked out of the box? You bet.

I still have the issue if the yubikey is plugged in when the machine boots up, but if I plug it in after the boot process is finished, all works as expected. I suspect this is something related to usb device initialization and the pcsc daemon not being able to obtain access to the USB device early on in the boot process. Just a wild guess though, so if you KNOW the solution, please, I’m all ears :-)