fix(yubikey): drop AddKeysToAgent — ssh-agent can't re-prompt for the FIDO2 PIN#302
Merged
Conversation
When SSH config sets 'AddKeysToAgent yes' and the IdentityFile is a
FIDO2 (*-sk) key with verify-required, the first ssh call works (touch
+ PIN, key cached in agent), but every subsequent call fails with:
sign_and_send_pubkey: signing failed for ED25519-SK "..." from agent:
agent refused operation
git@github.com: Permission denied (publickey).
Reason: ssh-agent on macOS (and most platforms) has no UI to re-prompt
for a FIDO2 PIN, so the cached entry refuses every signing op after the
first one. Workaround was 'ssh-add -D' before every push, which is awful.
Fix: for the YubiKey path, set 'IdentitiesOnly yes' instead and don't
ask the agent to cache anything. The FIDO2 private key never leaves the
YubiKey, so 'caching' it in the agent only buys us the broken state.
OpenSSH talks to the YubiKey directly each time and the touch + PIN
dance stays interactive.
yk-enroll's Done. block updated to describe the new behaviour.
Docs: docs/yubikey.md gained a 'Why not AddKeysToAgent yes?' section
with the agent-refused error verbatim and the 'ssh-add -D' recovery.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reported in chat. Sequence on macOS:
Root cause
~/.ssh/confighadAddKeysToAgent yesfor the YubiKey path. Firstsshworked because no key was in the agent yet — OpenSSH talked to the YubiKey directly, did the FIDO2 touch+PIN dance, then cached the handle inssh-agent. Every subsequentsshwent through the agent, which cannot re-prompt for the FIDO2 PIN (especially on macOS), so the cached entry just refuses every signing op withagent refused operation.Fix
For the FIDO2 path, set
IdentitiesOnly yesand don't ask the agent to cache anything:Host * User <user> {{- if and .useYubiKey $hasSkKey }} - AddKeysToAgent yes + IdentitiesOnly yes # ... IdentityFile linesThe private key never leaves the YubiKey, so "caching it in the agent" only buys us the broken state. OpenSSH talks to the YubiKey directly each time and the touch+PIN dance stays interactive and reliable.
yk-enroll'sDone.block updated to describe the new behaviour. Doc gained aWhy not AddKeysToAgent yes?section with the verbatim error message and thessh-add -Drecovery for anyone landing on this from the broken state.Recovery for already-stuck users
Verify
18/18 green (no test changes needed; tests don't assert on the SSH config wording).
Files
home/private_dot_ssh/config.tmpl—AddKeysToAgent yes→IdentitiesOnly yes+ comment block explaining whyhome/dot_config/shell/functions/yk-enroll.sh— updatedDone.step-2 wordinghome/dot_config/fish/functions/yk_enroll.fish— samedocs/yubikey.md— new "Why not AddKeysToAgent yes?" section