Deploying FIDO2 Passwordless Auth on Linux Servers

Your Windows and macOS endpoints went passwordless six months ago, but your developers still SSH into production servers with passwords. This inconsistency isn't just a gap; it's a direct path to your most sensitive systems.

Linux servers and developer workstations often sit closer to production databases, configuration management systems, and deployment pipelines than any user-facing device in your environment. If you're running passwordless on corporate laptops but relying on passwords for infrastructure, you're leaving high-value targets exposed to credential phishing and replay attacks.

RSA's recent extension of its passwordless platform to Linux environments, built on FIDO standards, offers a way to close that gap. Here's how to deploy FIDO2 passwordless authentication on Linux systems from planning through validation.

What You Need Before Starting

Infrastructure requirements:

• Linux servers or workstations running a supported distribution (verify compatibility with your chosen FIDO2 provider)
• Existing identity platform capable of FIDO2 enrollment and credential management
• Hardware security keys or platform authenticators (YubiKey, Titan Security Key, or TPM-backed credentials)
• SSH daemon version 8.2 or later for OpenSSH FIDO support
• PAM (Pluggable Authentication Modules) configuration access on target systems

Access and permissions:

• Root or sudo access to target Linux systems
• Identity platform administrator role for credential policy configuration
• Network connectivity between Linux systems and your identity provider's FIDO2 endpoints

Pre-deployment decisions:

• Credential type: hardware security keys, platform authenticators, or both
• Fallback authentication method during rollout (don't cut off emergency access)
• Scope: start with developer workstations or jump servers before production infrastructure
• Break-glass procedure for scenarios where FIDO2 authentication fails

Step-by-Step Implementation

1. Configure Your Identity Platform for FIDO2 Enrollment

Register your Linux systems as relying parties in your identity platform. Define:

• Allowed authenticator types (platform vs. cross-platform)
• User verification requirements (PIN, biometric, or both)
• Attestation requirements (none, indirect, or direct)
• Credential timeout and re-authentication policies

If you're using RSA ID Plus or a similar platform, create a policy group specifically for Linux systems. Set user verification to required to ensure every authentication includes a local check that can't be phished.

2. Install and Configure PAM Modules for FIDO2

On each target Linux system, install the necessary PAM modules to support FIDO2 authentication. For systems using pam_u2f:

sudo apt-get install libpam-u2f  # Debian/Ubuntu
sudo yum install pam-u2f         # RHEL/CentOS

Create a FIDO2 credentials directory:

sudo mkdir -p /etc/u2f_mappings
sudo chmod 755 /etc/u2f_mappings

Configure PAM by editing /etc/pam.d/common-auth (Debian/Ubuntu) or /etc/pam.d/system-auth (RHEL/CentOS). Add this line before the standard password authentication:

auth required pam_u2f.so authfile=/etc/u2f_mappings/u2f_keys cue

The cue parameter prompts users to touch their security key.

3. Enroll User Credentials

Each user needs to register their FIDO2 credential. Have users run:

pamu2fcfg -u$(whoami) > ~/.config/u2f_keys

When prompted, insert and touch the security key. The command generates a credential mapping and stores it in the user's home directory. For centralized management, collect these mappings and place them in /etc/u2f_mappings/u2f_keys with this format:

username:credential_key_handle,credential_public_key

4. Configure SSH for FIDO2 Authentication

OpenSSH 8.2+ includes native FIDO2 support. Generate a FIDO2 SSH key:

ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

The -sk flag indicates a security key. You'll be prompted to touch your hardware authenticator during key generation. The private key stub remains on the security key; the public key goes in ~/.ssh/authorized_keys on target servers.

For resident keys (credentials stored on the security key itself):

ssh-keygen -t ecdsa-sk -O resident -f ~/.ssh/id_ecdsa_sk

Update /etc/ssh/sshd_config to prefer public key authentication:

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

Restart the SSH daemon:

sudo systemctl restart sshd

5. Set Up Session Policies and Timeout Rules

Configure your identity platform to enforce re-authentication intervals. For privileged sessions on production servers, set maximum session duration to 8 hours with re-authentication every 2 hours. This limits the window of a compromised session without disrupting normal workflows.

In RSA ID Plus or equivalent platforms, create a policy that requires FIDO2 re-authentication when:

• Accessing production systems
• Elevating to root or sudo
• Initiating SSH sessions to systems tagged as critical infrastructure

Validation: How to Verify It Works

Test credential authentication:

Attempt to SSH into a configured server. You should see a prompt to touch your security key:

ssh [email protected]
Confirm user presence for key ECDSA-SK SHA256:...
User presence confirmed

If the connection succeeds without requesting a password, FIDO2 authentication is working.

Verify PAM integration:

Check /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) for successful FIDO2 authentications:

pam_u2f(sshd:auth): Authenticated user 'username' with security token

Test fallback scenarios:

Temporarily remove your security key and attempt authentication. The connection should fail cleanly without falling back to password authentication. If it falls back to passwords, review your PAM configuration, required should block authentication if FIDO2 fails.

Confirm phishing resistance:

FIDO2 credentials are origin-bound. Attempt to use a credential registered for server-a.example.com to authenticate to server-b.example.com. The authentication should fail unless both servers share the same relying party identifier in your identity platform.

Maintenance and Ongoing Tasks

Vault Rotation:

Unlike passwords, FIDO2 credentials don't require periodic rotation. The private key never leaves the hardware authenticator, and each authentication generates a unique signature. However, you should:

• Re-enroll credentials when users replace lost or damaged security keys
• Revoke credentials in your identity platform when users leave the organization
• Audit credential mappings quarterly to remove orphaned entries

Monitor authentication logs:

Set up alerts for:

• Repeated FIDO2 authentication failures (possible lost key or hardware issue)
• Successful authentications from unexpected IP ranges
• Fallback to password authentication (indicates misconfiguration or bypass attempt)

Update break-glass procedures:

Maintain a secure, documented process for emergency access when FIDO2 authentication fails. Consider:

• Time-limited root passwords stored in a vault, accessible only through multi-person approval
• Dedicated break-glass accounts that bypass FIDO2 requirements but trigger immediate security team notification
• Out-of-band verification for any break-glass access (phone call, separate authentication channel)

Expand coverage incrementally:

Start with developer workstations and non-production servers. Once you've validated the configuration and user workflow, expand to:

• Jump servers and bastion hosts
• Production application servers
• Database servers
• Container orchestration control planes

For financial services, government agencies, and energy-sector infrastructure, the environments RSA is targeting with this capability, prioritize systems that handle sensitive data or control critical operations. These are exactly the systems where passwordless coverage has lagged and where the risk of credential-based attacks is highest.