My ~/.ssh/id_rsa_yubikey.pub contains the output of ssh-add -L.
When I use ssh -T git@github.com to test my ssh connection, I get the window popup that asks me to insert my hardware key. However, even after I insert it and press OK, the prompt simply repeats itself, as if it cannot see the key.
I tried stopping the pcscd service in case there is an issue and I restarted scdaemon and gpg-agent with gpgconf --kill scdaemon and gpgconf --kill gpg-agent, but nothing has worked so far.
Also, you might need to make sure your SSH_AUTH_SOCK environment variable is pointing to your running gpg-agent (e.g. export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"). See the gpg-agent man page for an example snippet that you might need to add to your bashrc file.
You only want one of the keys that ssh-add -L lists in your ~/.ssh/id_rsa_yubikey.pub file. On my system, the rsa public key that ssh-add -L shows and that comes from my gpg-agent has a comment at the end that starts with cardno: followed by my YubiKey’s serial number.
Thanks for the quick response. I’ve read some of your articles on the Fedora magazine!
The command does not see my YubiKey. The SSH_AUTH_SOCK variable is set in my .bashrc as
# See the info page of gnupg, `info "(gnupg)Agent Examples"`
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
The ssh-add -L command lists a single key; shows a (none) but isn’t that just a comment?
I have that export in my .bashrc. The debug output mentions gpg: DBG: chan_3 <- ERR 100696144 No such device <SCD>. Is it related? The debug output is:
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: enabled compatibility flags:
gpg: DBG: [no clock] start
gpg: DBG: chan_3 <- OK Pleased to meet you, process 18825
gpg: DBG: connection to the gpg-agent established
gpg: DBG: chan_3 -> RESET
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION ttyname=/dev/pts/0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION ttytype=xterm-256color
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION display=:0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION xauthority=/run/user/1000/.mutter-Xwaylandauth.5GFO51
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=XMODIFIERS=@im=ibus
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=WAYLAND_DISPLAY=wayland-0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=XDG_SESSION_TYPE=wayland
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION putenv=QT_IM_MODULE=ibus
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION lc-ctype=en_US.UTF-8
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION lc-messages=en_US.UTF-8
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.4.0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION allow-pinentry-notify
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD GETINFO version
gpg: DBG: chan_3 <- D 2.4.0
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> SCD SERIALNO
gpg: DBG: chan_3 <- ERR 100696144 No such device <SCD>
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
gpg: DBG: [no clock] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0
gpg: objcache: uids=0/0/0 chains=0,0..0 buckets=0/0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks
Does the device show up in dmesg and have access nodes under /dev?
$ dmesg | grep Yubico
[ 911.819397] usb 1-2.4: Manufacturer: Yubico
[ 911.863297] input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2.4/1-2.4:1.0/0003:1050:0407.0006/input/input25
[ 911.915537] hid-generic 0003:1050:0407.0006: input,hidraw3: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:10.0-2.4/input0
[ 911.917978] hid-generic 0003:1050:0407.0007: hiddev97,hidraw4: USB HID v1.10 Device [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:10.0-2.4/input1
$ ls -lZ /dev/hidraw*
crw-rw----+ 1 root root system_u:object_r:usb_device_t:s0 241, 0 Jun 3 18:04 /dev/hidraw0
crw-rw----+ 1 root root system_u:object_r:usb_device_t:s0 241, 1 Jun 3 18:04 /dev/hidraw1
crw-rw----+ 1 root root system_u:object_r:usb_device_t:s0 241, 2 Jun 3 18:04 /dev/hidraw2
crw-rw----+ 1 root root system_u:object_r:usb_device_t:s0 241, 3 Jun 3 18:19 /dev/hidraw3
crw-rw----+ 1 root root system_u:object_r:usb_device_t:s0 241, 4 Jun 3 18:19 /dev/hidraw4
Edit: It looks like ACLs are being used to grant access on those device nodes (indicated by the + in the above ls output). You might also verify that your account is listed as having access to whatever device nodes are mapped to your YubiKey.
It seems that something is blocking gpg-agent from accessing the yubikey. Maybe SELinux?
Edit: Also, try running gpg-connect-agent updatestartuptty /bye right before running gpg --card-status to be sure that the agent is using the current tty.
You might try running gpg --card-status without other programs that access the YubiKey running. Sometimes one program can hold a “lock” on a file that prevents other programs from accessing it at the same time.
Also, if you are trying to access the YubiKey from within a container, there may be container-level sandboxing rules that are blocking access to the device.
You might try running lsof /dev/hidraw{3,4} (substituting the numbers with those from your dmesg output) to see if any running daemons are holding locks on the YubiKey.
I tried your SELinux suggestion but reading the AVC logs instead of disabling enforcement with ausearch -m avc --start recent, however there was nothing related in the output. I’ve tried disabling the PCSC daemon (and then YubiKey Authenticator doesn’t work) but still nothing.
I’m not trying to access the YubiKey from a container, in fact it works from the YubiKey Auth flatpak and from native Firefox, but not from native gpg.
There are no locks reported on the YubiKeys with lsof.
I will go through the bugzilla thread and try their suggestions and will report back with results.
I don’t know if it would make any difference to the problem you are experiencing, but I use a different variable to point ssh at my gpg-agent. I haven’t experienced the problem you mention. But my setup is quite different in many other ways. (I mostly use the Chrome browser and the Sway window manager.) But I do use both gpg-agent and ssh-agent at the same time with my YubiKey. To do so, I set SSH_AUTH_SOCK_GPG instead of SSH_AUTH_SOCK in my bash startup scripts.
export GPG_TTY="$(tty)"
if [[ -z $SSH_AUTH_SOCK_GPG ]]; then
export SSH_AUTH_SOCK_GPG="$(gpgconf --list-dirs agent-ssh-socket)"
fi
gpg-connect-agent updatestartuptty /bye &> /dev/null
Then, for the servers that I want to use my gpg rsa key, I put the following in my ~/.ssh/config.
Uninstalling opensc is not a solution - I would like to use PIV support of my Yubikey in Firefox and Thunderbird.
I’ve tried to install scute, but couldn’t to configure it to work. I’ll try it again when I get some spare time.