auth: FIDO2 / hardware security key connect polish

[Petyok]

Motivation

Hardware-backed keys (ed25519-sk, ecdsa-sk, touch/PIN via FIDO2) already work for many users through OpenSSH + the system authenticator, but SSHub gives little feedback: no “touch your key” affordance, weak failure messaging, and no Keys-tab distinction for security-key identities.

Proposal

• Detect -sk key types in the Keys UI; label them clearly.
• During connect, surface a non-blocking status (“waiting for security key touch / PIN”) driven by ssh/askpass or known sk prompts — align with the interactive auth modal work in auth: interactive password popup on connect, with a save offer and 3 attempts #52 where possible.
• Document platform prerequisites (udev, ssh-agent, native dialogs).
• Fail closed with a readable error when the authenticator is missing or the user cancels.

Non-goals

• Reimplementing FIDO in-process.
• Storing WebAuthn credentials inside SSHub.

Depends / related

• auth: interactive password popup on connect, with a save offer and 3 attempts #52 (auth modals / askpass channel) should land first or in tandem for prompt UX.
• Certificate issue if orgs combine sk keys + SSH certs.

Priority

Medium — important for security-conscious fleets; OpenSSH does the hard part.

Written by Grok 4.5 (Cursor) on behalf of the maintainer.

[Petyok]

The proposal says the touch affordance is "driven by ssh/askpass". I believe that is wrong, but I could not measure it — there is no hardware key on this machine — which is why the issue now carries needs-PoC.

My expectation, to be confirmed with a real key before any code:

• OpenSSH prints Confirm user presence for key ED25519-SK SHA256:… on stderr, as a notification rather than a question. There is nothing to answer: the answer is a fingerprint touch on the device.
• Askpass is used for the PIN on a key configured with one (verify-required), not for presence. And auth: interactive password popup on connect, with a save offer and 3 attempts #52 sets SSH_ASKPASS_REQUIRE=force, so a PIN prompt would arrive through that channel while the presence notice would not.

If that holds, the two halves come from different places: the presence affordance is parsed out of the -v stream the session already captures (Session::diagnostics, the same place CONNECTED_NEEDLES is matched, src/session/mod.rs:846), and only the PIN goes through #52's modal. Designing both onto the askpass channel would produce a modal that never opens.

What the spike should record, with the exact strings, since a needle table will be built from them:

1. ed25519-sk without a PIN: what appears on stderr, at what point, and whether askpass is invoked at all.
2. The same key with verify-required: what askpass receives in argv[1].
3. Cancelling the touch (never touching, then timing out) and pulling the key mid-prompt: what ssh prints and what it exits with.
4. Whether an -sk key in ssh-agent changes any of the above.

The Keys-tab half needs no hardware: -sk shows up in the key type string, so labelling security-key identities can land independently of the connect-time work.

Written by Claude Opus 5 (Claude Code) on behalf of the maintainer.