Daniel Nashed's Blog

Modern SSH Authentication with FIDO2 Security Keys (ed25519-sk)

Back in 2020, I described a “Paranoid SSH” setup using:

• Public key authentication
• Password authentication
• TOTP via Google Authenticator
• Hardware-protected OTP storage

That gave me something close to 3–4 factors.
Today, there is a cleaner and cryptographically stronger way:

FIDO2-backed SSH keys using ed25519-sk

• No shared secrets.
• No PAM modules.
• No TOTP seeds in home directories.
• No passwords required.

What Is an sk-SSH Key?

When you see a key like this:
sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5...

The sk- prefix means: Security Key backed.
The private key is not stored on disk.


It lives inside a hardware device such as a YubiKey.
OpenSSH delegates signing operations to the hardware token via FIDO2.

Security Model


With a hardware-backed SSH key, authentication requires:

1. Possession – The physical security key
2. Knowledge – The PIN protecting the key
3. Presence – Touch confirmation on the device

Unlike TOTP:

• No shared secret is stored server-side
• No secret file exists in ~/.google_authenticator
• No replayable codes
• No PAM dependency
  
  

Even if the server is fully compromised, the attacker gains:

• Only the public key
• No reusable secret
• No ability to generate signatures

Authentication strength does not degrade with server compromise.

Generating a FIDO2 SSH Key

Requirements:

• OpenSSH ≥ 8.2
• A FIDO2-compatible security key (e.g., YubiKey 5 series)

Generate a hardware-backed key:
ssh-keygen -t ed25519-sk -O resident -O verify-required


Options explained:

• ed25519-sk → Hardware-backed ED25519 key
• -O resident → Store credential inside the security key
• -O verify-required → Require PIN verification for every authentication
  
  

You will be prompted for:

• FIDO2 PIN
• Touch confirmation
  
  

This creates:

• id_ed25519_sk
• id_ed25519_sk.pub
  
  

Important:

• The file id_ed25519_sk is not the private key. It is only a reference stub.
• The real private key never leaves the hardware.

Installing the Public Key on the Server

As usual:
ssh-copy-id -i id_ed25519_sk.pub user@server

Or manually append to:
~/.ssh/authorized_keys


Using the Key

Now simply connect:
ssh user@server

You will see:
Confirm user presence for key ED25519-SK

Then:

1. Enter PIN
2. Touch the key
3. Login succeeds

No password required.


Why resident Matters


Using -O resident stores the credential inside the security key.
You can later retrieve it on another machine once the Yubikey is available via USB.
This reconstructs the stub file from the hardware.
Without -O resident, losing the stub file would make the credential unusable.


ssh-keygen -K


Comparison: TOTP vs FIDO2 SSH

Feature	TOTP + PAM	FIDO2 ed25519-sk
Shared secret on server	Yes	No
Secret in home directory	Yes	No
Replayable codes	Possible	No
Hardware enforced	Optional	Yes
Offline brute-force protection	No	Yes (PIN retry limits)
PAM required	Yes	No

FIDO2 replaces password + TOTP stacks with:

• Asymmetric cryptography
• Hardware-enforced signing
• Built-in rate limiting

Minimal Server Configuration


You can now simplify SSH configuration significantly:
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
AuthenticationMethods publickey

• No password fallback.
• No TOTP.
• No additional modules.

What Happens During Authentication

1. Server sends a random challenge
2. Client forwards challenge to the security key
3. Security key verifies PIN
4. User confirms presence (touch)
5. Security key signs challenge
6. Server verifies signature using stored public key

The private key never leaves the hardware.

Operational Considerations

• Register at least two security keys
• Store a backup in a safe location
• Document recovery procedure
• Avoid keeping password fallback enabled
  

If the security key is lost:

• Revoke its public key from authorized_keys
• Enroll a new hardware key

Conclusion

FIDO2-backed SSH keys replace:

• Password authentication
• TOTP-based 2FA
• Shared-secret models

With:

• Hardware-protected asymmetric cryptography
• PIN-enforced access
• User-presence confirmation
• Zero shared secrets
  

For hardened infrastructure, this is a cleaner and stronger model than traditional “multi-factor via PAM”.

• Comments [0]