Page MenuHome GnuPG

Yubikey 5 NFC only recognized immediately after it is inserted
Open, NormalPublic



I have Yubikey 5 NFC (two of them, they behave the same way): I have a PIN-protected gpg subkey there, which I want to use with gpg-agent for SSH authentication. It mostly works, but only when I attempt to make a SSH connection in a few seconds after the key was inserted. If I do that, it works even for subsequent connections in the future (tested at least several hours). However, when I wait for about 10 seconds or more before making the SSH connection, the GPG agent repeatedly requests that I insert the key (it is already inserted and visible in the lsusb output). gpg-card says "End of file" then.

When I pull the key from the USB slot and insert it back, I am able to enter the PIN and use it as SSH key (provided that I do it in a few seconds after the key is inserted).

The scdaemon log can be seen at .

It _might_ be that somebody else (Firefox?) attempts to use another applet inside the Yubikey shortly after I insert the key or something like that. What else should I do in order to pinpoint the source of the problem?

Thanks for any hints.

Event Timeline

There is a "sharing violatation", error which means another process got access to the card. You can try to put


into scdaemon.,conf to workaround it; this usually works but due to internal caching you may sometimes run intolittle problems.

@werner: thanks, with the 'pcsc-shared' option it works for me (after sending SIGHUP to scdaemon, of course). So, do I understand correctly that this cannot be the default?


Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I found that there are many such solutions on the Internet. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings.

There are reasons why we don't used pcsc-shared by default; for example: Not all OpenPGP cards support reading the current verification state (whether a PIN has already been entered) and thus we use a local cache for this. Other shared applications may change the state behind our back or even switch to another application on the card. Thus we use the safe way.

werner triaged this task as Normal priority.May 13 2022, 3:46 PM