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).
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.
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?
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 enable-ssh-support.
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.
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
/run/user/1000/gnupg/S.gpg-agent.ssh
[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…
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.
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.
Enabling 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
Either adding 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.
The 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.
I’ve noticed that if the key is plugged into the computer before turning it on then I have to restart pcscd to get it to work.
If the YubiKey is not plugged in before booting and I plug it in when I’m already at my desktop the SSH key appears just fine.
My guess is that since the YubiKey is plugged in when the computer starts and the pcscd is a system service vs gpg-agent being a user service, pcscd starts earlier, sees the YubiKey ant takes exclusive access of it. Later scdaemon starts and can’t access it. Restarting pcscd releases the YubiKey and scdaemon can take control of it so the SSH key shows up.
I don’t know how openSUSE does it but I didn’t have this problem on Tumbleweed about a month ago when I was still using it on the same computer with the same YubiKey and the same configuration (except I had KDE instead of Gnome).
Is there a way to make pcscd not take exclusive access or somehow ignore YubiKeys?
One of the suggestions of uninstalling the opensc package and having disable-ccid in ~/.gnupg/scdaemon.conf seems to do the trick. On boot the SSH key is available without doing anything, PIN caching works (unlike with pcsc-shared), hot-plugging works.