FiloSottile
yubikey-agent blocks Yubikey Manager
At least on macOS, if I have yubikey-agent running and I have authenticated with it (just starting yubikey-agent does not reproduce the problem), Yubikey Manager hangs. It appears to hang in a call to PCSC, and with some experiments the PIV application seems to be where it blocks - which makes sense obviously.
I'm creating this to make a reminder now to document this behavior in upcoming README (including how to stop the agent if Yubikey Manager is needed). Depending on how setup will work, maybe the Yubikey Manager is not needed by general audience but there needs to be a way to free the interface (easiest to stop the agent). Feel free to close/replace with some other TODO of course.
Yup, same with gpg-agent, seems to be a PCSC limitation. We'll definitely document this. There's also go-piv/piv-go#47 upstream to look into ways to make this better.
The interface is released on SIGHUP, so you can use killall -HUP yubikey-agent.
FYI, this workaround seems to fix a similar issue when using ykman oath code --single ... as well.
Just so it's searchable here's the error you get when trying this when yubikey-agent is running:
Error: Failed connecting to YubiKey 5 [FIDO+CCID]. Make sure the application have the required permissions.
Interestingly, my YubiKey 5 seems to persist the PIN cache across sessions, and even yubikey-agent restarts (but not unplug-replug cycles, as expected). In this case it would be far more acceptable to just drop the session every time.
I bet using a different applet will still trash the PIN cache, but that's probably ok.
Huh, it might be that PIN caching has always spanned sessions, but on older firmwares getting the serial number requires switching applets, so effectively we were dropping it at every session. Maybe there's an argument for not taking an exclusive lock, and just not reading the serial on older firmwares.
Hi! I want to use yubikey-agent for a very few SSH keys. Mostly, the ones for sites that don't support ed25519-sk keys.
This issue is a a big pain, especially because I use the yubikey as a FIDO device a lot too as well as for GPG.
I wouldn't mind having to type the PIN each time I use yubikey-agent if that's the price for it to not lock my yubikey the rest of the time.
Is this approach somehow possible? I think it could be a useful solution for some until upstream unblocks this issue.
Wouldn't #44 essentially solve this? launchd also supports socket activation. Here's the launchd config and associated socket activation code I use in piv-agent. It's only lightly tested on macOS since I don't use that OS regularly, but it does work:
https://github.com/smlx/piv-agent/blob/main/deploy/launchd/com.github.smlx.piv-agent.plist
https://github.com/smlx/piv-agent/blob/main/internal/sockets/get_darwin.go
I may not fully understand the context here, but it might be more worthwhile overall to place some efforts on this PR on the upstream piv-go library: https://github.com/go-piv/piv-go/pull/100
This will allow yubikey-agent and piv-agent to Open SHARED access to the key, and avoid blocking other applications which do the same ( like ssh-agent, p11-kit, etc ).
https://github.com/go-piv/piv-go/issues/47#issuecomment-1280781982
Looks like the PR for piv-go is stuck.
Would it make sense to build a broker that could be used by this project and others? Though it would be difficult to get projects to adopt it.
