Zero-Trust SSH Access Blueprint: FIDO2 Hardware Keys & SSH Certificate Authority

Executive Summary

Executive Summary & Key Security Takeaways

← Back to Articles

Cyber Security • Zero Trust SSH
Zero-Trust SSH Access Blueprint: FIDO2 Hardware Keys & SSH Certificate Authority

By Zyekh Abdul Qadir Jailani
Published: August 3, 2026
8 min read (1,250+ Words)

    Share
    Download .md
    Download .pdf

Zero-Trust Infrastructure Blueprint for FIDO2 Hardware Tokens & SSH Certificate Authority

Executive Summary & Key Security Takeaways

• Eliminate Static Keys: Migrate from static authorized_keys deployment to short-lived SSH Certificates.

• FIDO2 Hardware Bound: Enforce ed25519-sk key pairs tied to physical security tokens (YubiKey/FIDO2).

• Centralized Authority: Use an offline SSH Certificate Authority (CA) to sign user access requests with automatic 8-hour expiration.

• Zero Administrative Sprawl: Adding or revoking user permissions requires zero modifications on target servers.

Table of Contents

• 1. The Problem with Static SSH Public Keys
• 1. Hardware Security Keys: OpenSSH FIDO2 / U2F
• 1. Setting Up a Centralized SSH Certificate Authority
• 1. Related Privacy & Security Tools
• 1. Verification & Security Audit Checklist
• 1. Frequently Asked Questions (FAQ)

Traditional SSH key management across growing server fleets suffers from a critical flaw: static public key sprawl. Managing thousands of ~/.ssh/authorized_keys files across production instances creates massive administrative overhead, increases the blast radius of compromised developer workstations, and makes offboarding security audits nearly impossible.

A true Zero-Trust SSH Access Model replaces static SSH keys with two cryptographic pillars:

• FIDO2 / Security Key Hardware Tokens (ed25519-sk): Private key material never leaves the physical YubiKey token and requires physical touch plus user PIN.

• SSH Certificate Authority (SSH CA): Short-lived SSH certificates (e.g., valid for 8 hours) signed by a centralized CA key, eliminating manual authorized_keys deployment.

1. The Problem with Static SSH Public Keys

In standard SSH deployments, when an engineer needs access to a production server, their public key is appended to the server's authorized_keys file. Over time, this leads to significant vulnerabilities:

• No Expiration: Public keys remain valid indefinitely until manually purged.

• Workstation Compromise: Unprotected SSH private keys stored on developer disk drives can be exfiltrated by malware.

• Lack of Centralized Revocation: Revoking access requires executing cleanup scripts across every instance.

2. Hardware Security Keys: OpenSSH FIDO2 / U2F

Since OpenSSH 8.2, native support for security keys (FIDO2 / U2F) is supported via the ed25519-sk and ecdsa-sk key types. Key generation requires the physical hardware token connected to the machine.

# Generate an SSH key backed by a hardware token with user-presence verification
ssh-keygen -t ed25519-sk -O touch-required -C "[email protected] (YubiKey)"

[ NOTE ] For enhanced security, generate resident keys (discoverable credentials) with PIN protection so the key stub can be retrieved directly from the token on new devices:

# Generate a resident key with mandatory PIN and touch requirement
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "[email protected] (Resident)"

3. Setting Up a Centralized SSH Certificate Authority

Instead of copying individual public keys to every target machine, servers are configured to trust a single CA Public Key. The CA signs engineer public keys with short expiration times and restricted permissions.

Step A: Generate the CA Key Pair

Generate a secure host CA key on an isolated offline machine or Hardware Security Module (HSM):

# Generate the SSH Certificate Authority key pair
ssh-keygen -t ed25519 -f /etc/ssh/ca/ssh_user_ca -C "Production SSH User CA 2026"

Step B: Configure Target Linux Servers to Trust the CA

On all Linux production servers, place the CA public key in /etc/ssh/ssh_user_ca.pub and update /etc/ssh/sshd_config:

# Append to /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/authorized_principals/%u

Create principal definitions for target system accounts (e.g., /etc/ssh/authorized_principals/ubuntu containing the line admin-role).

Step C: Signing User Keys with Expiration & Principals

When an engineer requests access, the CA signs their public key to produce a certificate (id_ed25519_sk-cert.pub):

# Sign engineer's public key valid for 8 hours for principal 'admin-role'
ssh-keygen -s /etc/ssh/ca/ssh_user_ca \
  -I "[email protected]" \
  -n "admin-role" \
  -V +8h \
  -z 20260803001 \
  id_ed25519_sk.pub

4. Related Privacy & Security Tools

To assist with infrastructure configuration, security audits, and key validation, use these privacy-first client-side web tools:

• Secure Password & Passphrase Generator -> Generate high-entropy PINs for hardware tokens.

• Cryptographic Hash Generator -> Verify SHA-256 fingerprints of SSH public keys and certificates.

• Side-by-Side Diff Checker -> Audit differences between server sshd_config templates.

• Environment Variables & Secrets Formatter -> Format SSH environment variables safely in-browser.

5. Verification & Security Audit Checklist

Verify that your setup enforces Zero-Trust principles using the following checklist:

# Inspect certificate properties and expiration details
ssh-keygen -L -f id_ed25519_sk-cert.pub

# Test SSH login using explicit certificate credential
ssh -i id_ed25519_sk -i id_ed25519_sk-cert.pub [email protected]

6. Frequently Asked Questions (FAQ)

What happens when an SSH certificate expires?

      Once the certificate validity period expires (e.g., +8h), OpenSSH automatically rejects all authentication attempts using that certificate. No server-side cleanup or manual key removal is required.

Can FIDO2 SSH keys be used without internet connectivity?

      Yes. OpenSSH communicates directly with the FIDO2 hardware token over USB/NFC via standard libfido2 drivers, requiring zero external internet connection.

Written by Zyekh Abdul Qadir Jailani

Digital Forensics & Incident Response (DFIR) Specialist & Security Researcher specializing in Linux kernel hardening, threat hunting, and system security research.

LinkedIn •
GitHub •
Discord •
Email •
PGP Key

Utility Security Tools Related to this Article:

    Gunakan Secure Password Generator kami untuk membuat kata sandi root/SSH yang acak dan kuat, atau gunakan Diff Checker untuk membandingkan perubahan berkas sysctl/SSH secara side-by-side.



© 2026 zyekh.com — Portal Hub

  About
  ·
  42 Web Tools
  ·
  25 Articles
  ·
  Blueprints
  ·
  llms.txt (RAG Base)

Originally published at https://zyekh.com/blog/zero-trust-ssh-access-with-fido2-and-ssh-ca.html