Simone Orsi
All posts
·sshyubikeysecuritydevops

SSH Agent Forwarding with FIDO2 Keys: The Missing PIN Dialog

Why verify-required YubiKeys fail with agent forwarding, and the one-line fix nobody mentions.

I've been using FIDO2 keys for SSH and git signing for a while now, but there's one configuration that broke my brain for days: getting verify-required keys to work with SSH agent forwarding.

This assumes ForwardAgent yes is set for your target host in ~/.ssh/config.

Most people either give up on agent forwarding entirely or disable the PIN requirement. Both are terrible compromises.

The real problem isn't the forwarding itself — it's that when your remote VM tries to use your forwarded key, the ssh-agent on your local machine has no way to prompt you for the PIN. The agent just fails with agent refused operation and everyone assumes forwarding is broken.

What's missing from every guide I found: you need a GUI dialog system that works even when the request comes from a remote machine.

The Missing Piece

The fix is stupidly simple once you know it: install ssh-askpass and force the agent to use it.

brew tap theseal/ssh-askpass
brew install ssh-askpass

Then tell your shell to always use it:

export SSH_ASKPASS=ssh-askpass
export SSH_ASKPASS_REQUIRE=force

Now when your VM tries to sign a git commit, the PIN dialog pops up on your Mac — exactly where it should be, since that's where your YubiKey is.

Why This Matters

Without this setup, you're forced into bad security tradeoffs:

  • Copy private keys to VMs (defeats the point of hardware keys)
  • Disable PIN requirements (makes your key less secure)
  • Sign commits locally and push (breaks collaborative workflows)
  • Use separate keys for different environments (key management nightmare)

With proper forwarding, your workflow becomes: VM requests signature → PIN dialog on your Mac → touch YubiKey → signed commit appears on VM. The private key material never leaves your hardware token, the PIN never crosses the network.

What This Changes

Once you have this working, you can sign commits from any VM or container while keeping your keys on dedicated hardware. No more choosing between security and convenience.

I use this setup for signing commits in development VMs, CI environments, and even Docker containers. The security model stays clean: hardware token never leaves my machine, PIN entry happens locally, but signed artifacts appear wherever I'm working.

The frustrating part is how simple the fix is once you know it exists. Most SSH agent forwarding guides assume password-protected keys or ignore FIDO2 entirely. The ssh-askpass requirement for hardware tokens with PINs is barely documented anywhere.

If you're using hardware keys and avoiding agent forwarding because of PIN prompts, try this setup. It's the difference between compromising your security model and actually using it everywhere.