SSH Hardening in Production: Hardware FIDO2 Keys, Bastion Jump Hosts & Disabling Password Auth Forever

The Persistent Vulnerability of Password Authentication and File-Based Keys

In modern infrastructure management, SSH remains the ubiquitous command-and-control conduit for Linux systems. Yet across thousands of enterprise audits, system administrators continue to tolerate hazardous legacy patterns: password authentication left enabled for convenience, root logins allowed over public networks, and private RSA key files stored unencrypted on developer laptops.

When a developer laptop is compromised by infostealer malware, unencrypted files in ~/.ssh/id_rsa or ~/.ssh/id_ed25519 are exfiltrated within seconds. Attackers scan company repositories on GitHub to correlate keys with public IP addresses, granting them unrestricted root access to core production clusters. By 2026, securing remote administration demands adopting FIDO2/U2F hardware-backed keys, strictly enforced bastion jump topologies, and the permanent eradication of password authentication.

FILE-BASED KEYS VS. FIDO2 HARDWARE BACKED SSH

• VULNERABLE (TRADITIONAL FILE-BASED KEYS): Developer Laptop → ~/.ssh/id_ed25519 (Stored on Disk)
• (Malware Exfiltration Risk)
• Dark Web / Attacker Root Access
• SECURE (HARDWARE FIDO2 TOKENS / ED25519-SK): Developer Laptop → Stub File Pointers Only
• (Physical Touch Required)
• YubiKey Hardware Token: Cryptographic Sign in Secure Element
• Authenticated OpenSSH Session to Production Server

At Webxtek, zero-trust operations dictate that administrative credentials must never exist as exportable secrets. By combining hardware authentication with our audited technical consulting, organizations protect critical workloads from account takeover attacks.

FIDO2 Security Keys: Provisioning ed25519-sk Tokens

OpenSSH natively supports FIDO2 security keys via the ed25519-sk (security key) algorithm. Unlike traditional keypairs where the private key sits on your filesystem, an ed25519-sk keypair stores only a key handle on the machine. The true private key remains locked inside the hardware security module of your USB-C or NFC security key.

To generate a resident FIDO2 key that requires both user presence (physical touch) and user verification (a hardware PIN), run:

# Generate resident hardware-backed SSH key with PIN requirement
ssh-keygen -t ed25519-sk -O resident -O verify-required -f ~/.ssh/id_ed25519_sk_prod

# Inspect public key output format
ssh-keygen -y -f ~/.ssh/id_ed25519_sk_prod

FIDO2 ED25519-SK CHALLENGE-RESPONSE FLOW

• 1. Client Requests SSH Connection to Target Node
• 2. Server Sends Random Cryptographic Nonce Challenge
• 3. Client SSH Passes Challenge to Hardware Key via USB HID
• 4. Hardware Key Flashes LED & Demands Physical Finger Touch
• 5. Internal Secure Element Signs Nonce with On-Chip Private Key
• 6. Signed Nonce Sent Back to Server → Connection Granted!

Even if an attacker gains root access to your local development machine, they cannot initiate an SSH session to production servers without physically pressing the gold contact on your hardware token.

Hardening /etc/ssh/sshd_config: Banishing Legacy Cryptography

Default OpenSSH configurations prioritize backward compatibility over security. On enterprise Debian installations, default settings allow obsolete key exchange algorithms and permit root password brute-forcing.

Deploy the following hardened configuration to /etc/ssh/sshd_config.d/99-hardened.conf:

# Restrict port and listen address
Port 2222
AddressFamily inet

# Authentication Policies
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# Session Security & Disconnects
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Disable Insecure Protocol Features
X11Forwarding no
AllowTcpForwarding yes
AllowAgentForwarding no

# Strict Modern Cryptographic Primitives (Reject Weak RSA and SHA-1)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com

Before restarting the SSH daemon, always validate the syntax in a separate terminal:

# Test configuration syntax without restarting daemon
sshd -t

# Reload OpenSSH service safely
systemctl reload ssh

Following hardening principles outlined by OWASP ensures that automated vulnerability scanners find no exploitable cryptographic weaknesses.

Bastion Jump Hosts: Securing Private Subnets with ProxyJump

Directly exposing database nodes, storage servers, and internal application workers to public internet IPs is an architectural failure. In a resilient production deployment, only a hardened bastion jump host receives a public IP address. All other nodes sit within an isolated private network.

ZERO-TRUST BASTION TOPOLOGY WITH PROXYJUMP Operator Laptop (With YubiKey) (Public Internet SSH / Port 2222) HARDENED BASTION JUMP HOST Public IP: 203.0.113.10 (No application code, no databases) (Private VLAN 10.10.0.0/24 / Zero Public IPs)

• App Node 01: 10.10.0.15
• PostgreSQL DB: 10.10.0.22

Operators should never use legacy ssh -A (SSH agent forwarding) because a compromised intermediate host can hijack the forwarded agent socket. Instead, leverage modern ProxyJump (-J), which establishes an encrypted TCP tunnel through the bastion directly to the destination node.

Configure your local ~/.ssh/config file:

# Bastion Gateway Node
Host bastion.internal
    HostName 203.0.113.10
    Port 2222
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519_sk_prod

# Production Database Server (Private Subnet)
Host db01.prod
    HostName 10.10.0.22
    User postgresadmin
    ProxyJump bastion.internal
    IdentityFile ~/.ssh/id_ed25519_sk_prod

Connecting to the database server is executed with a single command: ssh db01.prod. OpenSSH transparently tunnels the connection through the bastion while keeping cryptographic negotiation strictly between your laptop and the final server.

Session Auditing, Break-Glass Accounts, and Fleet Maintenance

Eliminating individual SSH accounts on servers leads to accountability gaps unless accompanied by centralized logging. Every successful and failed authentication must be routed to a centralized audit journal. Configure /etc/ssh/sshd_config to use LogLevel VERBOSE to record the fingerprint of the exact public key utilized for every login.

For catastrophic outage recovery (such as hardware token loss during transit), establish a sealed “break-glass” procedure. Store offline cryptographic keys in physical bank vaults or tamper-evident hardware safes.

Coupling hardened SSH access with professional managed hosting services and scheduled system maintenance contracts protects enterprise Linux environments from unauthorized access while maintaining rapid, audited operational agility.

In practice, we apply these exact architectural standards across specialized sectors including extreme cybersecurity & pen-testing and b2b cybersecurity & corporate intelligence. Whether you are modernizing core workflows through technical consulting before you build and managed hosting for websites and apps, connecting sector-specific requirements to disciplined execution is what turns technical theory into compounding commercial advantage.