Securing SSH with FIDO2/U2F: A Step-by-Step Guide to YubiKey Hardware Authentication

Introduction: The Imperative for Hardware-Backed SSH Security

In the modern enterprise infrastructure landscape, Secure Shell (SSH) access represents the keys to the digital kingdom. For decades, standard practices transitioned from vulnerable password-based authentication to asymmetric cryptographic key pairs (such as RSA or Ed25519). While cryptographic key pairs are significantly more secure than passwords, they possess a fundamental architectural vulnerability: they are software-based assets. If an engineer's local workstation is compromised via malware, session hijacking, or sophisticated phishing attacks, the underlying private key files stored on disk can be exfiltrated and cloned without the operator's knowledge.

To solve this fundamental flaw, the industry has shifted toward hardware-backed cryptographic credentials. By leveraging the Fast IDentity Online (FIDO2) and Universal 2nd Factor (U2F) protocols, organizations can anchor their SSH authentication workflows directly into physical security keys, such as the YubiKey. In this implementation, the cryptographic private key never leaves the secure element of the hardware device, rendering remote key exfiltration structurally impossible. This comprehensive guide details the configuration, deployment, and operational maintenance of SSH over FIDO2/U2F.

1. Understanding FIDO2/U2F Mechanics in SSH

Beginning with OpenSSH version 8.2, native support was introduced for FIDO2 and U2F electronic tokens. This paradigm introduced two new key types to the OpenSSH ecosystem: ecdsa-sk and ed25519-sk (where "sk" denotes "Security Key").

When utilizing these protocols, the mechanism changes from a standard file-on-disk model to one of two structural configurations:

Non-Resident Keys (Standard FIDO2/U2F): The local workstation holds a small "key handle" file. When an SSH connection is initiated, this handle is passed to the YubiKey. The YubiKey uses its internal, immutable master key to derive the actual private key on-the-fly, validates the cryptographic challenge, and returns only the signature to the host system.
Resident Keys (Discoverable Credentials): The cryptographic reference is stored entirely within the persistent internal memory of the YubiKey itself. This allows administrators to walk up to any trusted workstation, execute an SSH command, and authenticate without needing a local key file on disk, pulling the credential directly from the physical token.

Furthermore, FIDO2 introduces explicit User Presence (UP) and User Verification (UV). User Presence requires a physical touch on the YubiKey capacitive contact to prove a human operator is executing the command, blocking automated malware attacks. User Verification forces the input of a hardware-bound PIN, establishing true multi-factor authentication (Something You Have + Something You Know) in a single unified step.

2. Prerequisites and Environmental Alignment

Before proceeding with implementation, verify that both the client machine and the target remote server satisfy the necessary software version bounds:

OpenSSH Version: Both client and server endpoints must run OpenSSH 8.2 or higher. For optimal cryptographic efficiency and performance, OpenSSH 8.4+ is recommended. Check your current version using ssh -V.
YubiKey Hardware: A YubiKey 5 Series, YubiKey 5 FIPS Series, or Security Key by Yubico supporting FIDO2/U2F capability.
Middleware/Libraries: On Linux client systems, ensure the FIDO communication layer is present by installing libfido2 via your native package manager (e.g., apt install libfido2 or dnf install libfido2).

3. Step-by-Step Client Key Generation

Step 3.1: Hardware Initialization and PIN Enforcement

To maximize security via User Verification, ensure your YubiKey has an active FIDO2 PIN configured. This can be accomplished globally via the graphical Yubico Manager tool or via the command line using the Yubico Authenticator tool.

Step 3.2: Generating the Hardware-Backed Key Pair

Insert your YubiKey into an available USB port on the client machine. Open your terminal emulator and execute the following key generation command. We choose ed25519-sk due to its superior performance, security profile, and fixed signature sizes:

ssh-keygen -t ed25519-sk -O resident -O verify-required -C "yubikey-fido2-ssh-key"

Let us deconstruct the operational flags utilized in this command:

-t ed25519-sk: Specifies the creation of an Ed25519 key backed by a hardware security token.
-O resident: Instructs the system to store the credential directly inside the YubiKey memory as a discoverable resident key, easing cross-workstation portability.
-O verify-required: Explicitly configures the key metadata to require User Verification (PIN input) during any subsequent authentication lifecycle.
-C: Appends an administrative comment string to identify the identity artifact easily.

Upon execution, the terminal will prompt you to enter the YubiKey's FIDO2 PIN. Following successful verification, the status indicator LED on your physical YubiKey will begin flashing. Physically tap the gold contact sensor to confirm human presence and complete the cryptographic generation process.

By default, this will write two files to your local ~/.ssh/ directory: id_ed25519_sk (the local key stub/handle) and id_ed25519_sk.pub (the public key component).

4. Server-Side Configuration and Hardening

With the cryptographic token generated, the public aspect must be authorized on the target infrastructure nodes.

Step 4.1: Exfiltrating and Deploying the Public Key

Extract the string contents of your public key artifact using the utility tool of your preference:

cat ~/.ssh/id_ed25519_sk.pub

The output structure will resemble the following signature format:

ssh-ed25519-sk AAAAGnNzaC1lZDI1NTE5LXNrAAAA... yubikey-fido2-ssh-key

Append this exact string line into the ~/.ssh/authorized_keys file on the remote server instance assigned to your user account. Ensure file permissions are strictly locked down to prevent structural rejections by the SSH daemon:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

Step 4.2: Enforcing Hardware-Only Access in sshd_config

To ensure security compliance across infrastructure segments, you must explicitly configure the OpenSSH daemon (sshd) to accept hardware-backed keys while phasing out standard legacy keys. Open the configuration file /etc/ssh/sshd_config on the remote server with root privileges:

sudo nano /etc/ssh/sshd_config

Modify or append the following directives to align with strict hardware access protocols:

# Disable legacy password authentication completely
PasswordAuthentication no

# Enable public key authentication mechanics
PubkeyAuthentication yes

# Restrict allowed key algorithms to security-key primitives exclusively
PubkeyAcceptedKeyTypes [email protected],[email protected]

Operational Risk Advisory: Restricting PubkeyAcceptedKeyTypes strictly to sk- variants will instantaneously terminate access for any traditional software-based SSH keys currently configured within your fleet. Ensure extensive canary testing is performed before widespread automated deployment.

Validate the structural syntax of your updated daemon configuration before reloading the live production process:

sudo sshd -t

If no errors are displayed, apply the configuration adjustments immediately by restarting the service daemon:

sudo systemctl restart ssh

5. Operational Authentication Workflow

To connect to the remote architecture with your hardened hardware asset, invoke the standard SSH client connection string:

ssh user@remote-server-ip

The runtime sequence will execute smoothly under the following conditions:

The host machine initiates a handshake with the remote endpoint and detects that a security key type is required.
The terminal will prompt you to enter your alphanumeric FIDO2 PIN locally to satisfy the User Verification (UV) assertion constraint.
The YubiKey LED indicator will change to an active blinking status. Physically touch the sensor contact to validate User Presence (UP).
The secure element signs the inbound challenge packet internally, transfers the cryptographic proof back to the SSH client agent, and establishes your shell access securely.

Conclusion: Embracing Passwordless Infrastructure Hardening

Migrating enterprise remote administration protocols away from static file-based SSH credentials to hardware-enforced FIDO2/U2F validation paths represents a massive leap forward in perimeter defense strategy. By requiring physical touch assertions coupled with hardware PIN isolation, the entire attack surface related to credential theft, automated phishing, and workstation key extraction is nullified. While the initial setup requires careful software version validation, the resulting long-term protection provides robust assurance for mission-critical infrastructure systems.