After fixing the lock issue with my Yubikey here: Pcscd has to be restarted at every boot to get my SSH keys from my YubiKey
The Yubikey now constantly asks for a password when using SSH. Usually this was cached until the Yubikey was re-inserted, or when the cache TTL was hit. Over the ~5 years I’m using a Yubikey this behavior has changed throughout software updates (meaning, it’s a bit buggy).
I have the following configs:
reader-port Yubico Yubi
But I still get prompted for every SSH connection. Is this something common? If not, please share your configs and experience. It may also be a bug with new software releases, but before I’ll bug devs with this, I want to make sure it’s not a config issue.
Also asked this question on Reddit:
Not buggy per se. Software updates may change what happens and how it happens without being classed a bug. No updates → no changes → also no improvements.
It has been a buggy experience for sure. The documentation also still lists these settings and function, if that doesn’t work (or only from time to time), then that’s buggy, right?
But to be on topic, it does work fine for you?
I use a YubiKey to store my SSH and GPG keys. There are a few configuration requirements:
enable-ssh-support in .gnupg/gpg-agent.conf
export GPG_TTY=$(tty) in .bashrc.d/gpg-tty.conf
SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh in .config/environment.d/10-ssh-auth-sock.conf
Hidden=true in .config/autostart/gnome-keyring-ssh.desktop - this is a copy of /usr/etc/xdg/autostart/gnome-keyring-ssh.desktop with that addition
Item 3 specifies the correct SSH socket to use for gpg-agent’s implementation of ssh-agent.
Item 4 disables ssh-agent which would otherwise be started by default.
Logout and login again and you should only be prompted for your YubiKey user-password on the first ssh client invokation.
Cool! I’ll check this out later this week. Just for reference, did you get these options from a how-to or something like that? Then I can maybe read some more about it, the reasoning behind some of these options and things like that. The
SSH_AUTH_SOCK is something I already use, as well as the
Do you use Silverblue or something else? Because the
/usr/etc/xdg/autostart/gnome-keyring-ssh.desktop is at
/etc/xdg/autostart/gnome-keyring-ssh.desktop on my system.
Just did a quick test, doesn’t work for me, probably it’s a combination of other GPG/SSH settings. Will mess with it later a bit more and collect logs. I’m also using tmux, so my
tty will always change with every tmux window/pane switch. Not sure if that config will work for me. But I guess the
GPG_TTY is only used when using the curses password prompt?
I guess you used this as a source? Because then I also don’t have to do the GNOME keyring thing, because it doesn’t interfere with my SSH agent.
Can you share what else you have in gpg-agent.conf and scdaemon.conf? Your using Fedora 36? Which Yubikey? And it really asks only once to unlock the SSH key from your Yubikey? After that it’s cached for an X amount of time?
I don’t use howtos and generate my configurations from original reference material (manpages, project websites etc.). That article is a happy coincidence.
I disable the ssh-agent because it was overriding the setting of SSH_AUTH_SOCK from .config/environment.d/10-ssh-auth-sock.conf.
I don’t have a scdaemon.conf file and my gpg-agent.conf only contains enable-ssh-support.
The files in /etc/xdg/autostart just appear to be mutable versions of those in /usr/etc/xdg/autostart. The file sizes are are the same for both.
I’m running fedora Silverblue 36 and the stock GNOME desktop. The setting of GPG-TTY is mandated in the gpg-agent manpage.
My YubiKey is a Version 4 which I’ve been running using this setup for a couple of years on both fedora Workstation and Silverblue.
Note that using silverblue or using Workstation WILL result in different paths & procedures since by default silverblue is built differently and is immutable.
Okay thanks for the info! Just to double confirm the expected outcome, you only have to unlock your authentication GPG key once for SSH, right? After that a certain TTL is used to clear the cache? Or do you have to re-insert your Yubikey to get another prompt?
Yes. I can, for example, use Remmina to SSH into a remote host and I’m prompted for my YubiKey user password to unlock it. After closing Remmina and using “ssh” in a terminal to SSH into a remote host doessn’t require me to re-enter the YubiKey password.
If I remove the YubiKey from the USB slot, and re-plug it, I will be required to enter the YubiKey user password again. All of this functionality is also subject to gpg-agent cache TTLs but I don’t set anything specific and just use the defaults.
Can you show your output of this?
ps -ef | grep keyring
user 1418 1 0 08:06 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login
It doesn’t use the
ssh switch there. I’m now testing it in a Silverblue VM and passtrhough’ed the Yubikey. The key is available in the VM, but the
SSH_AUTH_SOCK is not created. Probably because there is no daemon running that should provide this. I also couldn’t get
gnome-keyring-ssh.desktop to use
/usr/bin/gnome-keyring-daemon --start --components=ssh.
I also tried manually. Killed the original keyring daemon and then started it like this.
[user@fedora autostart]$ ps -ef | grep keyring
user 14167 1399 0 08:12 ? 00:00:00 gnome-keyring-daemon --start --components=ssh --daemonize
user 14176 14098 0 08:12 pts/0 00:00:00 grep --color=auto keyring
[user@fedora autostart]$ gpg --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device
[user@fedora autostart]$ echo $SSH_AUTH_SOCK
[user@fedora autostart]$ ll /run/user/1000/gnupg/S.gpg-agent.ssh
srwx------. 1 user user 0 Jul 27 08:12 /run/user/1000/gnupg/S.gpg-agent.ssh
[user@fedora autostart]$ ssh-add -l
The agent has no identities.
Ah, wait, now it does work! Had to reinsert it into the VM. Now I only have to make the
gnome-keyring-daemon respect the SSH component…
There’s some confusion here.
The purpose of the .desktop file in .config/environment.d is to disable gnome-keyring’s ssh-agent functionality. That functionality is then provided by gpg-agent.
gnome-keyring’s management of SSH keys is separate and works with programmatic access via the gnome-keyring API. I use that facility for a statically configured SSH key (in .ssh) for use with PikaBackup to allow scheduled backups of my system without the need for the YubiKey to be present.
Odd, because the SSH component is not even started automatically, at least, when looking at the running process:
/usr/bin/gnome-keyring-daemon --daemonize --login
You also don’t have one of these sockets enabled? I’ve then disabled.
systemctl --user is-active gpg-agent-browser.socket gnome-keyring-daemon.socket gpg-agent-extra.socket gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket
I do have a Yubikey 4 NEO laying around somewhere. Maybe it has to do with that. Because in the past it worked fine as well. Hard and software changes have taken place.
I do have the gpg-agent-* sockets enabled (they are in /etc/systemd/user/sockets.target.wants). Some, or all of them, will be required for proper operation of gpg-agent.
I don’t think there’s any difference between a YubiKey 4 and 5 in this context so I would continue testing with your currently-configured key.
The problem really seems to be
pcscd fighting with the GPG scdaemon. Which I already knew from other posts, blogs and logs. But after hours of troubleshooting I haven’t arrived at any other conclusion. I don’t see how GNOME interferes. The
Hidden=true in that autostart file doesn’t make it work for me.
pcscd: 00019213 winscard.c:286:SCardConnect() Error Reader Exclusive
Or GPG’s scdaemon:
scdaemon pcsc_connect failed: sharing violation (0x8010000b)
shared-access in the scdaemon.conf does fix that, as also suggested in the Yubikey docs:
However, then the password is not cached.
Killing GPG or restarting the
pcscd often does calm down this lock battle and then things work fine. The Yubikey is detected in an instant and caches the password as long as the Yubikey is not re-inserted. So to me that feels like a bug or some kind of misconfiguration, but don’t know what.
What works for others
disable-ccid to the scdaemon.conf or disabling the
pcscd.socket works for other people. This seems to be a mutual exclusive solution. Either one works, but not combined. For me none work. Disabling
pcscd.socket makes the Yubikey undetectable. And adding the
disable-ccid doesn’t change the behavior. I also tried adding the
reader-port Yubico Yubi line to the scdaemon.conf, as was suggested by Yubico. But no luck either.
disable-ccid thingy should fix it, according to Yubico.
What works for me
My silly workaround is this
alias yk-ssh='until ssh-add -l 1>/dev/null; do continue; done' to steal the lock and re-inset the Yubikey a few times. But it’s a dumb fix, if you can even call it like that.
I’ve looked through my logs and I have both pcscd and scdaemon executing.
pcscd is, for the most part, quiet (it starts and listens on its socket which is enabled in /etc/systemd/system/sockets.targets.wants.
scdaemon is more verbose mostly complaining that it can’t find any readers but the YubiKey is detected and password prompts are recorded. I don’t have any specific configuration for scdaemon i.e. no .gnupg/scdaemon.conf
The only showstopper I encountered in setting all of this up was to disable gnome-keyring’s ssh-agent support (via the .desktop file Hidden=true entry) to prevent it overwriting the SSH_AUTH_SOCK environment variable with its own.
Interesting. Because even when I do force GNOME keyring to use the SSH component, it’s using a different path for the local socket. And it’s not overwriting the
SSH_AUTH_SOCK variable. Maybe it’s still a Yubikey 4 versus 5 issue, or Silverblue vs Workstation. Or perhaps some other config that’s different.