DEV Community

Aomi Qaza
Aomi Qaza

Posted on • Originally published at zyekh.com

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

#security #linux #devops #architecture

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
Enter fullscreen mode Exit fullscreen mode

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 "engineer@company.com (YubiKey)"
Enter fullscreen mode Exit fullscreen mode

[ 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 "engineer@company.com (Resident)"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 "engineer@company.com" \
  -n "admin-role" \
  -V +8h \
  -z 20260803001 \
  id_ed25519_sk.pub
Enter fullscreen mode Exit fullscreen mode

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 engineer@server.company.com
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)