What Is SSH? Secure Shell Architecture, Ed25519 Keys & Hardening Guide (2026)

Secure Shell (SSH) is the standard cryptographic network protocol defined by the Internet Engineering Task Force (IETF RFC 4251) for executing commands, managing infrastructure, and tunneling traffic safely across untrusted networks. Unlike legacy plaintext protocols such as Telnet or FTP, SSH binds every session with three separate cryptographic guarantees: server host-key authentication, ephemeral forward-secret key exchange, and authenticated symmetric encryption.

Loading configuration...

1. How the SSH Protocol Stack Works (RFC 4251–4254)

Many introductory tutorials describe SSH as a single encryption wrapper, where “the client encrypts a command with a public key and the server decrypts it with a private key.” That description is technically incorrect. Asymmetric public-key cryptography is only used to verify identities and establish a shared session secret; the actual terminal keystrokes and file transfers are encrypted with fast, symmetric Authenticated Encryption with Associated Data (AEAD) ciphers such as chacha20-poly1305@openssh.com or aes256-gcm@openssh.com.

The IETF specification splits SSH-2 into three modular layers that execute sequentially on TCP port 22:

1. The Transport Layer Protocol (RFC 4253): Negotiates protocol versions, runs the ephemeral Diffie-Hellman or hybrid post-quantum key exchange (KEX) to derive symmetric session keys, verifies the server’s host public key against your local ~/.ssh/known_hosts file, and provides per-packet confidentiality and integrity checking.
2. The User Authentication Protocol (RFC 4252): Runs inside the encrypted transport tunnel to prove the connecting user’s identity to the server using public-key signatures (publickey), FIDO2 hardware tokens (sk-ssh-ed25519), OpenSSH certificates, or PAM multi-factor challenges (keyboard-interactive).
3. The Connection Protocol (RFC 4254): Multiplexes the single encrypted TCP connection into multiple logical channels—simultaneously supporting interactive shell sessions (pty-req), SFTP file transfers, and local or remote TCP port forwarding without opening additional firewall ports.

2. Empirical Comparison: Ed25519 vs. Ed25519-SK vs. RSA-4096 vs. Legacy RSA-SHA1

When generating an SSH key pair in 2026, algorithm selection directly determines public-key wire size, brute-force resistance of the encrypted private key file, and resistance to side-channel timing attacks. The table below summarizes our local OpenSSH key-generation and verification measurements alongside their governing IETF standards:

3. Post-Quantum SSH Key Exchange: Why OpenSSH 9.9+ Uses mlkem768x25519-sha256

Even if an attacker cannot forge your ssh-ed25519 login signature today, a passive network adversary recording encrypted SSH traffic at an ISP or data-center boundary could store the captured ciphertext and decrypt the session later once a cryptanalytically relevant quantum computer (CRQC) breaks classical Elliptic Curve Diffie-Hellman (curve25519-sha256).

To neutralize this harvest-now, decrypt-later (HNDL) threat without sacrificing the proven classical security of Curve25519, OpenSSH introduced hybrid post-quantum key exchange:

• OpenSSH 9.0 to 9.8: Defaulted to sntrup761x25519-sha512@openssh.com (Streamlined NTRU Prime combined with X25519).
• OpenSSH 9.9 and 10.0+ (2025–2026 Default): Prioritizes mlkem768x25519-sha256, which pairs the NIST-standardized Module-Lattice Key-Encapsulation Mechanism (NIST FIPS 203 ML-KEM-768) with classical X25519. Because both shared secrets are concatenated into the SHA-256 key derivation function (KDF), the resulting session key remains secure as long as either ML-KEM-768 or X25519 remains unbroken.

You can verify which key-exchange algorithm your SSH client negotiates in real time by passing the verbose -v flag and inspecting the kex: algorithm: line:

ssh -v -o ConnectTimeout=5 git@github.com 2>&1 | grep -E "kex: (algorithm|host key|server->client)"

4. Step-by-Step: Generating Hardened Ed25519 & FIDO2 Hardware SSH Keys

4.1 Standard Workstation Key with 100-Round Bcrypt KDF

On Windows 11 (PowerShell or OpenSSH Client), macOS, or Linux, generate a dedicated Ed25519 key pair using -a 100 (100 rounds of the bcrypt key-derivation function to slow down offline passphrase cracking if your laptop disk is ever compromised):

ssh-keygen -t ed25519 -a 100 -C "workstation-2026" -f ~/.ssh/id_ed25519_prod

When prompted, enter a strong passphrase. This command writes two files into your ~/.ssh/ directory:

• id_ed25519_prod: Your encrypted private key (permissions must be chmod 600 on Linux/macOS; never copy or upload this file to any remote server).
• id_ed25519_prod.pub: Your public key (a single line starting with ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... that you append to the remote server’s ~/.ssh/authorized_keys file).

4.2 Hardware-Bound FIDO2 Security Key (ed25519-sk)

If you have a FIDO2 hardware security key (such as a YubiKey 5 or Token2 key) and OpenSSH 8.2+, you can generate an SSH key whose private key stays permanently locked inside the hardware token’s secure element and requires a physical touch plus PIN on every login:

ssh-keygen -t ed25519-sk -O resident -O verify-required -C "fido2-bastion-key" -f ~/.ssh/id_ed25519_sk

5. Production sshd_config Server Hardening Checklist

Before exposing any Linux server to the public internet, place a drop-in configuration file at /etc/ssh/sshd_config.d/99-infosiast-hardening.conf (using the interactive generator at the top of this guide) and validate syntax before reloading the daemon:

1. Verify your public key login works in a second terminal tab first: Never disable password authentication until you have confirmed key-based login succeeds with sudo privileges in a separate open session.
2. Test configuration syntax with sshd -t: Run sudo sshd -t to check for syntax or algorithm errors before restarting the service. If sshd -t returns zero output, reload safely with sudo systemctl reload sshd (or sudo systemctl reload ssh on Debian/Ubuntu).
3. Disable AllowAgentForwarding on untrusted jump hosts: If you connect to an intermediate server with ForwardAgent yes, any user with root access on that server can connect to your local UNIX agent socket in /tmp/ssh-XXXX/ and use your keys to pivot to other machines. Use ProxyJump (ssh -J bastion.example.com target.internal) instead, which tunnels the end-to-end SSH handshake through the bastion without exposing your agent socket.

Written and prepared by Kshitij Gupta.