2

I am trying to debug why all of the sudden my Yubikey is taking very long to access. The Yubikey holds a GPG private key, that is then used for GPG and SSH. It was working just fine for several months and now it is taking several seconds just to complete a decryption or signature:

$ echo hi | time gpg --clearsign
...
gpg --clearsign  0.00s user 0.00s system 0% cpu 21.660 total

This used to be instantaneous. Seeing a rather round and reproducible delay I went hunting for the potential causes, and I have traced the issue through gpg-agent down to the scdaemon that is used to communicate with the actual smart card. Turning on logging on the scdaemon gives me this:

2023-08-04 16:02:01 scdaemon[197085] DBG: chan_7 <- SERIALNO
2023-08-04 16:02:11 scdaemon[197085] DBG: apdu_open_reader: BAI=94102
2023-08-04 16:02:11 scdaemon[197085] DBG: chan_7 -> S SERIALNO ABCD
2023-08-04 16:02:11 scdaemon[197085] DBG: chan_7 -> OK
2023-08-04 16:02:11 scdaemon[197085] DBG: chan_7 <- SERIALNO
2023-08-04 16:02:23 scdaemon[197085] DBG: apdu_open_reader: BAI=94102
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S SERIALNO ABCD
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> OK
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 <- GETATTR KEY-FPR
2023-08-04 16:02:23 scdaemon[197085] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0
2023-08-04 16:02:23 scdaemon[197085] DBG:  raw apdu: 00 CA 00 6E 00
2023-08-04 16:02:23 scdaemon[197085] DBG:  response: sw=9000  datalen=224
2023-08-04 16:02:23 scdaemon[197085] DBG:       dump:  6E 81 DD 4F ...
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S KEY-FPR 1 AXYZ
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S KEY-FPR 2 BXYZ
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> S KEY-FPR 3 CXYZ
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> OK
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 <- RESTART
2023-08-04 16:02:23 scdaemon[197085] DBG: chan_7 -> OK

Notice that there are two separate breaks, each of 10 seconds each. It appears to be attempting to read the serial number from the smart card if I'm reading the logs correctly.

What could be causing this delay? Could it be a network lookup that is failing after 10 seconds? And how can I address this issue and not have to wait 20-30 seconds on each git commit or ssh connection I do?

cdecker
  • 411
  • 2
  • 5
  • 18
  • Does this yubikey have the same delay regardless of which computer you use? Does a different yubikey have the same delay on this computer? Are other operations fast, such as status? https://developers.yubico.com/yubico-piv-tool/Actions/status.html – James T Aug 21 '23 at 04:31
  • 1
    Also please confirm your yubikey is authentic: https://www.yubico.com/genuine/ – James T Aug 21 '23 at 04:36
  • Thanks for commenting James, very good points that I should have clarified. The delay isn't always there, it appears to be related to suspending the notebook and then waking it up again. The more things I try the more I tend towards attributing the issue to DBUS being misconfigured (I'm running sway on Wayland on Ubuntu), and possible the gnome-keyring being unreachable. – cdecker Aug 21 '23 at 08:37
  • The yubikey is genuine, and I've only ever observed this issue on this machine, though as mentioned above, it comes and goes. – cdecker Aug 21 '23 at 08:38

0 Answers0