Killing Passwords for Good: Implementing FIDO2 Hardware Keys and Passkeys on Linux & Cloud

📖 Original Reference: Originally published with operating system hardening rules and cryptographic standards at alexmaina.dev/sicurezza.

SMS verification codes, email magic links, and standard Time-based One-Time Passwords (TOTP via authenticator apps) are no longer sufficient to stop modern adversary-in-the-middle (AiTM) reverse proxy phishing kits like Evilginx. These attacks intercept your session cookie right as you type your 6-digit code.

The only cryptographic authentication standard completely immune to phishing is FIDO2 / WebAuthn (Passkeys), backed by asymmetric public-key cryptography bound directly to the browser's origin.

Here is a practical guide to implementing FIDO2 hardware security keys (YubiKey, Nitrokey, or platform passkeys) across your development machines, Linux servers, and cloud consoles.

1. Why FIDO2 Beats Traditional 2FA

Under WebAuthn, your browser cryptographically signs the challenge with the private key stored inside the hardware token, verifying that the domain matches the origin. If you enter your credentials on g1thub.fake.com, the FIDO2 key simply refuses to sign the payload.

2. Hardening Linux Server SSH with FIDO2 Hardware Keys

Forget traditional vulnerable RSA/ED25519 SSH keypairs that sit unencrypted on your disk. OpenSSH has native support for FIDO2 hardware keys (ed25519-sk and ecdsa-sk).

Step 1: Generate a Resident FIDO2 SSH Keypair

Plug your hardware key into your local machine and run:

# Generate a hardware-backed resident key requiring user presence (touch)
ssh-keygen -t ed25519-sk -O resident -O verify-required -f ~/.ssh/id_ed25519_sk

• -O resident: Stores the key metadata directly in the hardware token. You can plug the key into any computer and pull your key with ssh-add -K.
• -O verify-required: Requires PIN entry on the physical key before it authorizes the connection.

Step 2: Configure Remote Server (/etc/ssh/sshd_config)

On your remote Ubuntu/Debian server, enforce hardware-only authentication:

# Disable password authentication and insecure key algorithms
PasswordAuthentication no
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes *[email protected]*
ChallengeResponseAuthentication no

Restart SSH: sudo systemctl restart ssh. Now, even if an attacker steals your local id_ed25519_sk file, they cannot connect without physically possessing and tapping your hardware key!

3. Securing Local Sudo on Linux with pam_u2f

Instead of typing your user password every time you run sudo:

# 1. Install the U2F PAM module
sudo apt install libpam-u2f pamu2fcfg -y

# 2. Register your physical key
mkdir -p ~/.config/Yubico
pamu2fcfg > ~/.config/Yubico/u2f_keys

# 3. Register your backup key (ALWAYS have a second key!)
pamu2fcfg -n >> ~/.config/Yubico/u2f_keys

Edit /etc/pam.d/sudo and add this line near the top:

auth required pam_u2f.so

Open a new terminal window to test: when you type sudo ls, your key will blink. Tap it, and sudo permissions are granted cryptographically without revealing a password.

4. The Golden Rule: The 2-Key Strategy (Primary + Backup)

Never configure a single hardware key. If you lose it while traveling, you risk locking yourself out of root consoles.

1. Primary Key: On your keychain (e.g. YubiKey 5C NFC).
2. Backup Key: Kept offline in a secure, fireproof safe at home or office.
3. Every time you register a passkey on GitHub, AWS, Google Cloud, or your password manager, enroll both keys simultaneously.

Conclusion

Migrating to FIDO2 hardware tokens and Passkeys transforms authentication from a memory test into cryptographic proof of physical possession. Phishing kits become obsolete, and credential theft is eliminated at the protocol layer.

Author: Alessandro Mainardi — Software Developer & Security Enthusiast. Read the complete systems hardening and privacy guide at alexmaina.dev/sicurezza.