search

drduh / YubiKey-Guide

Guide to using YubiKey for GnuPG and SSH
http://drduh.github.io/YubiKey-Guide/
MIT License
11.14k stars 1.19k forks source link

GPG acts like my YubiKey isn't plugged in #404

Closed Amolith closed 8 months ago

Amolith commented 10 months ago

It started happening seemingly at random, but I assume it was some package update that caused it. GPG is acting like my YubiKey doesn't exist even though ykman does detect it. gpg-agent refuses to start in the foreground no matter which flags and options I try and pcscd's logs don't seem to have anything useful either.

image

A few minutes after taking this screenshot, there was a line appended to pcscd's logs. I didn't do anything manual to trigger it that I'm aware of, just composing this issue.

Dec 04 12:32:32 angmar systemd[1]: pcscd.service: Deactivated successfully.

Any help debugging would be greatly appreciated.

EDIT: My OS is fully up-to-date (as of writing) Arch Linux.

Amolith commented 10 months ago

I don't know that the root issue is related to GPG or one of its components, but I'm tired of using PGP anyway and am taking this opportunity to abandon it.

I dug around to find some small, purpose-built tools to replace specific PGP features I currently rely on that also work well with my YubiKey. I've listed them below for others looking to do the same.

I do still have my PGP key on my YubiKey and would be happy to help debug this, but it's no longer an issue for me. I did mention this on the fediverse and someone replied saying they had a similar experience on a fresh Fedora 39 installation last week.

Paraphraser commented 10 months ago

I don't know whether any of this will help but I've had something roughly similar. I have three YubiKeys. Two are 5 NFC (like yours), the third is 5Ci, all provisioned identically as per Dr Duh.

One NFC lives in a safe as a backup; the others are in use. The NFC is employed where I have a USB-A port, the 5Ci where I only have USB-C ports. Right now, my circumstances are such that the:

In other words, the NFC gets connected to lots of things while the 5Ci is dedicated to the M2 MacBook Pro.

Other than something I will mention later, the in-use NFC has never misbehaved in the manner I am about to describe so this is strictly limited to the 5Ci.

The normal (expected behaviour) is:

  1. I connect the 5Ci to the laptop. It flashes a few times and then goes idle.
  2. I do something that requires its use (eg signing a commit for GitHub).
  3. I am prompted for the PIN which I enter.
  4. The YubiKey flashes waiting for a touch.
  5. I touch and the operation completes.

But for maybe one use in every ten:

  1. I connect the 5Ci to the laptop - flash - idle.
  2. I do something that requires its use.
  3. I am prompted to "please insert the card with serial number xx xxx xxx" where the serial number is that of the card which is inserted.

Experience has shown that none of the obvious measures gets me anywhere:

  1. Just yelling "look, you dumb thing, the YubiKey is already connected" and then pressing O (for OK) to retry.
  2. Pressing C (for Cancel) then retrying the original operation.
  3. Pressing C (for Cancel) then disconnecting and reconnecting the 5Ci, and then retrying the original operation.

If, however, I press C, leave the 5Ci connected, and then run a script containing these lines:

$ gpgconf --kill gpg-agent && gpgconf --launch gpg-agent
$ gpg-connect-agent "scd serialno" "learn --force" /bye
$ gpg --card-status

the problem goes away. All those lines are sourced from the Dr Duh readme but I don't think they occur together as a recipe (I think I got them from an issue). Anyway, that's the magic incantation that seems to work. I assume the first two lines are doing all the heavy lifting, and I can see the sense in that ordering (clobber and re-launch the agent so it develops amnesia, then probe the card to learn its characteristics).

Before purchasing the 5Ci, the only time I have seen anything close to this "connect an already-connected card" behaviour is if I have been doing things like updating the keys on both NFCs. In that situation I've been using multiple YubiKeys on the same system in a round-robin sequence so it makes (a kind of) sense that the various agents might get confused. But the same three-line repair works there too.

@Amolith - intriguing - thanks for the links - a fun afternoon's reading is ahead of me!

elliottminns commented 10 months ago

@Amolith Same issue here following Arch Linux update this morning

gpg --version
gpg (GnuPG) 2.4.3
libgcrypt 1.10.3-unknown
pcsc-lite version 2.0.1
Amolith commented 10 months ago

I just updated my laptop (also Arch) and noted which packages were updated that seemed like they could be related:

Before the update, GPG worked as it always has. After the update, I'm experiencing the same broken behaviour as on my desktop, shown in the first screenshot.

elliottminns commented 10 months ago

This is now working for me following upgrading Arch again this morning. Rolling release problems. 😅

I have a log of my upgraded packages if it's useful to anyone

upgraded.log

APraxx commented 8 months ago

Had same problem and found a solution in the arch gitlab It seems since GnuPG 2.4 a fallback was removed.

To quote the ArchWiki for GnuPG

Since version 2.4 however, you will have to add the disable-ccid option in ~/.gnupg/scdaemon.conf, to be able to use pcscd.

hope this helps someone

Paraphraser commented 8 months ago

@APraxx - Hah! That triggered a memory. See #256. That's almost 3 years ago and, although I've upgraded both Mac hardware (mixture of Intel and Apple silicon) and macOS (Ventura), a quick check reveals:

$ ls -l .gnupg/scdaemon.conf 
-rw-r--r-- moi  staff  73 May  9  2021 .gnupg/scdaemon.conf
$ cat .gnupg/scdaemon.conf 
pcsc-driver /System/Library/Frameworks/PCSC.framework/PCSC
disable-ccid

$
Paraphraser commented 8 months ago

Interestingly (at least to me) is the feedback surrounding #256 was that the pcsc-driver line was not needed. At the time I had a mixture of macOS releases (High Sierra thru Catalina). The pcsc-driver line was definitely needed on Catalina but not earlier. Nevertheless, it still fits with disable-ccid being needed on GnuPG version 2.3 and later.

Now I'm at macOS Ventura and the GnuPG installed by HomeBrew is 2.4.4 but my scdaemon.conf files have been inherited from the ancestor systems (ie still contain both lines). However, experimentation today shows that, not only is the pcsc-driver line not required on Ventura but it couldn't possibly work anyway. Why? Because:

$ file /System/Library/Frameworks/PCSC.framework/PCSC
/System/Library/Frameworks/PCSC.framework/PCSC: broken symbolic link to Versions/Current/PCSC

So, while the symlink file is there, the target isn't.

While researching that question, I stumbled across: pcsc-lite. I don't know how that is meant to fit in as a replacement. Right now disable-ccid seems to be enough so I'm going to put a pin in this.

Meanwhile, I observe that the Debian systems I'm using have GnuPG 2.2.27 (Bullseye) and 2.2.40 (Bookworm), plus 2.2.27 on Ubuntu Jammy Jellyfish.

I did a bit of digging around to see if I could explain the version gap between my Linux and macOS systems. There's a long thread at bugs.debian.org which runs from Oct 2022 thru Sep 2023 but still doesn't seem to have made a lot of progress. In short, a whole lot of "dunno".

What I can say, though, is that creating scdaemon.conf on Debian with just disable-ccid works. In other words, it doesn't cause any harm on GnuPG 2.2 systems. Therefore, I can't see any good reason not to make the creation of scdaemon.conf a standard part of the DrDuh guide. That way, anyone following the guide should have a smoother experience on 2.3-or-later versions of GnuPG.