SSH + FIDO2: Phishing-Resistant Admin Access (Practical Runbook)

For admin access, the real risk usually isn’t “is the password weak?” — it’s phishing and credential reuse. SSH faces a similar story: if the private key gets stolen, or agent forwarding is misused, lateral movement happens almost instantly.

The pragmatic move is to lean on OpenSSH’s security key support and tie admin access to a FIDO2 key + PIN + touch confirmation. In other words, the “private key file” alone shouldn’t be enough.

Prerequisites and limits

• The client’s OpenSSH must support “sk” (security key).
• A FIDO2 security key (YubiKey, etc.) is required.
• For some remote/automation scenarios, the “touch required” requirement means you need a careful plan.

1) Client: generate a FIDO2-backed SSH key

The basic command:

ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk_admin -C "admin-fido2"

The options I recommend:

• Require a PIN (verify required)
• Pick “resident key” only when you intentionally want it (manage the loss risk)

Example:

ssh-keygen -t ed25519-sk \
  -O verify-required \
  -f ~/.ssh/id_ed25519_sk_admin \
  -C "admin-fido2"

This typically prompts for PIN + touch at login.

2) Server: install the public key

For the matching user on the server:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
cat id_ed25519_sk_admin.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

3) sshd hardening: tighten step by step

In /etc/ssh/sshd_config I move incrementally:

1. First, confirm login works with the FIDO2 key
2. Then disable password authentication
3. Then disable / restrict root login

Example (illustrative):

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
AuthenticationMethods publickey

Followed by:

sudo systemctl reload sshd

4) Operations: design without breaking break-glass

The break-glass principles I push on the ground:

• A separate break-glass account, held by very few people
• Access is closed on “normal days” (e.g. firewall allowlist + temporary rule)
• Audit: every use is logged separately
• Regular rehearsals: 2–4 controlled tests a year

Extras that matter for FIDO2:

• If a key is lost: a spare and an approval process
• If a PIN is forgotten: a reset plan (most keys require a reset)

5) Day-2: agent forwarding and sudo risks

FIDO2 is very strong at login, but these still pose risk:

• ForwardAgent yes letting the key get reused on other hops
• Malicious processes on the host escalating via sudo

My practical kit:

• Use an admin bastion / management host and disable forwarding by default
• Narrow access with AllowUsers/AllowGroups
• Centralize sudo logs and produce alerts from them

6) Quick troubleshooting

What I see most often:

• Client OpenSSH doesn’t support “sk” → upgrade OpenSSH / install the right package
• The security key isn’t detected → USB permissions / udev / macOS permissions
• No PIN prompt appears → regenerate with -O verify-required

Conclusion

SSH + FIDO2 takes admin access out of the “was the key file stolen?” risk zone and reinforces it with user interaction. Done right, you raise phishing resistance and your break-glass reflex stays intact. The key points: roll out incrementally, manage automation accounts under a separate model, and turn drills into a routine.