Secure Linux SSH with YubiKey: A Complete FIDO2 Guide

Securing SSH access is essential for any Linux server that hosts websites, applications, or critical data. Password‑only logins are vulnerable to brute‑force attacks, phishing, and credential‑stuffing. Adding a hardware security key such as a YubiKey (FIDO2/U2F) provides a strong, phishing‑resistant second factor that remains effective even if a password is compromised.

Why Use a YubiKey for SSH?

• Phishing‑proof: The key never transmits a reusable secret that can be intercepted.
• Hardware‑bound: The private key never leaves the device, reducing the attack surface.
• Convenient: A single tap replaces a time‑consuming OTP or password entry.
• Compliance‑ready: Meets many regulatory requirements for multi‑factor authentication.

Prerequisites

1. A Linux server with the SSH daemon running (Ubuntu 22.04, Debian 12, AlmaLinux 9, Rocky 9, or RHEL 9).
2. A YubiKey that supports FIDO2/U2F.
3. Root or sudo privileges on the server.
4. A workstation (Linux, macOS, or Windows) with the YubiKey attached for testing.

1. Install Required Packages

The pam_u2f module and openssh-server package are needed on both Debian‑based and RHEL‑based systems.

Debian / Ubuntu

# apt update
# apt install libpam-u2f openssh-server

Updates the package index, then installs the PAM module that communicates with U2F devices and ensures the SSH server is present.

AlmaLinux / Rocky Linux / RHEL

# dnf install pam_u2f openssh-server

Installs the same PAM module for the RHEL family.

2. Create a U2F Device Mapping

The PAM module requires a mapping file that links each user to a specific YubiKey. Store the file in the user’s home directory as ~/.config/Yubico/u2f_keys.

Step‑by‑step (run as the target user on the server)

1. Create the configuration directory if it does not exist:

   $ mkdir -p ~/.config/Yubico
   

2. Insert the YubiKey and generate the mapping:

   $ pamu2fcfg > ~/.config/Yubico/u2f_keys
   

   The pamu2fcfg utility reads the key, prompts you to touch it, and writes a line containing the public key, key handle, and an identifier. PAM later uses this line to verify the tap.

3. Configure SSH to Use PAM and Public‑Key Authentication

Edit /etc/ssh/sshd_config to enable PAM, disable password authentication (optional but recommended), and keep public‑key authentication enabled.

Common changes (apply to all supported distributions)

# vi /etc/ssh/sshd_config

# Enable PAM integration
UsePAM yes

# Disable password logins (optional)
PasswordAuthentication no

# Keep public‑key authentication (required for YubiKey)
PubkeyAuthentication yes

# Require a public key plus a second factor
AuthenticationMethods publickey,password publickey,keyboard-interactive

Explanation: UsePAM yes tells SSH to delegate authentication to PAM modules. PasswordAuthentication no removes the fallback password path. The AuthenticationMethods line forces a two‑step process: a normal SSH key plus either a password or a keyboard‑interactive challenge—the latter will be satisfied by the YubiKey via PAM.

4. Add the PAM U2F Module to the SSH PAM Stack

Modify the PAM configuration file for SSH located at /etc/pam.d/sshd. Insert the U2F module before the line that permits public‑key authentication.

Debian / Ubuntu

# vi /etc/pam.d/sshd

# Add near the top:
auth required pam_u2f.so cue

# Existing lines (example)
@include common-auth
@includedir common-account
@includedir common-session

The cue option prompts the user to touch the key if no matching credential is found.

AlmaLinux / Rocky Linux / RHEL

# vi /etc/pam.d/sshd

# Insert:
auth required pam_u2f.so cue

# Follow with the default lines, e.g.:
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin

5. Restart SSH and Test the Setup

After editing the configuration, restart the SSH daemon and verify that you can still log in with your regular SSH key, then confirm the YubiKey prompt appears.

Restart the service

# systemctl restart sshd

Test login from your workstation

$ ssh -i ~/.ssh/id_rsa youruser@yourserver.example.com

You should see a prompt similar to:

Enter verification code: (touch your YubiKey)

Touch the YubiKey when prompted. If authentication succeeds, your SSH access is now protected by hardware‑based MFA.

6. Optional: Enforce YubiKey‑Only Logins

To eliminate password fallback entirely, adjust the AuthenticationMethods line in sshd_config to require the U2F factor explicitly:

AuthenticationMethods publickey,keyboard-interactive:pam

Because the only keyboard‑interactive method configured is pam_u2f, SSH will reject logins unless the YubiKey is present.

7. Managing Multiple Users and Keys

For each user who needs SSH access, repeat steps 2‑4 under that user’s account. The pamu2fcfg command stores a separate line per key, allowing a single user to register multiple YubiKeys (e.g., one for work, one for travel).

To revoke a key, edit ~/.config/Yubico/u2f_keys and remove the corresponding line. Restarting the SSH service is optional but ensures the changes take effect immediately.

Troubleshooting Common Issues

• No prompt appears: Verify that UsePAM yes is set and that the pam_u2f.so line exists in /etc/pam.d/sshd. Check the SSH daemon logs with journalctl -u sshd -f for PAM‑related errors.
• Authentication fails after touching the key: Ensure the user’s u2f_keys file contains the correct entry. Re‑run pamu2fcfg to regenerate it if necessary.
• Key not recognized from a different workstation: The mapping is stored on the server, not the client. As long as the same YubiKey is used, any client can authenticate.

Conclusion

Integrating a YubiKey with SSH adds strong, phishing‑resistant protection without adding significant complexity. By installing the PAM module, registering the hardware key, adjusting sshd_config, and testing the workflow, you can secure remote access to your Linux VPS or dedicated server hosted at AtoZNode. Regularly review the u2f_keys files and keep the YubiKey firmware up to date to maintain a robust security posture.