Which SSH ciphers should I use in 2026?

Prefer AEAD ciphers: chacha20-poly1305@openssh.com and aes256-gcm@openssh.com. They combine encryption and integrity, are fast with AES-NI, and are the OpenSSH defaults. AES-CTR is acceptable but needs a separate MAC.

What does encrypt-then-MAC mean?

Encrypt-then-MAC (the -etm suffix) computes the authentication tag over the ciphertext rather than the plaintext. It is the cryptographically preferred construction and resists several padding and integrity attacks, so prefer hmac-sha2-256-etm over the plain variant.

Why are CBC ciphers deprecated?

CBC-mode SSH ciphers are vulnerable to plaintext-recovery and Terrapin-class attacks because of how SSH frames packets. OpenSSH disables aes256-cbc and 3des-cbc by default. Use AEAD or CTR ciphers instead.

What is sntrup761x25519?

It is a hybrid post-quantum key exchange combining the NTRU Prime KEM with X25519. It protects session keys against future quantum attacks while staying secure against classical ones, and is the default key exchange in current OpenSSH.

Does this tool connect to my server?

No. It is a static offline reference and filter that runs entirely in your browser. Nothing is sent to any server.

What is the SSH Cipher Suite Reference?

Reference of OpenSSH symmetric ciphers, MAC algorithms and key-exchange algorithms with a security status for each, plus a live filter to harden your sshd_config. It runs free in your browser on Gera Tools, with nothing uploaded.

SSH Cipher Suite Reference

Name: SSH Cipher Suite Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Choosing strong SSH algorithms

Every SSH session negotiates three algorithm classes during the handshake: a symmetric cipher for the data stream, a MAC for integrity (unless an AEAD cipher provides it), and a key-exchange (KEX) algorithm to agree the session keys. This reference lists the common OpenSSH options in each class with a security status so you can harden sshd_config and your client config.

Algorithm quick reference

Recommended ciphers

Algorithm	Type	Notes
`[email protected]`	AEAD	Software-fast; preferred when AES-NI is absent
`[email protected]`	AEAD	Hardware-fast on AES-NI CPUs
`[email protected]`	AEAD	Slightly faster than 256-GCM, still strong

AEAD ciphers combine encryption and authentication in one pass, so a separate MAC is not negotiated.

Deprecated / avoid

Algorithm	Reason
`aes256-cbc`, `aes128-cbc`	CBC padding attacks; Terrapin vulnerability
`3des-cbc`	3DES is effectively broken for large data volumes
`arcfour*`	RC4 is cryptographically broken

Recommended MACs (for CTR ciphers only)

Algorithm	Notes
`[email protected]`	Encrypt-then-MAC; preferred
`[email protected]`	Encrypt-then-MAC; slightly faster

The -etm suffix means the HMAC covers the ciphertext, not the plaintext — the cryptographically preferred construction. Avoid hmac-sha1 and hmac-md5 entirely.

Recommended key exchange

Algorithm	Notes
`[email protected]`	Hybrid post-quantum + X25519; default in current OpenSSH
`curve25519-sha256`	X25519 ECDH; fast and strong classically
`diffie-hellman-group16-sha512`	RSA-world fallback; acceptable

Applying the config

SSH negotiation is preference-ordered: the client offers a list, the server picks the first mutually supported entry. Control the offered lists in /etc/ssh/sshd_config:

Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
KexAlgorithms [email protected],curve25519-sha256

Check what your installed build supports before editing:

ssh -Q cipher
ssh -Q mac
ssh -Q kex

Before you save and reload

Validate the config: sudo sshd -t
Reload in a separate process: sudo systemctl reload sshd (not restart)
Keep your existing session open while testing a new login — if the new config breaks authentication, your open session lets you revert without a console.

Locking yourself out of a remote server by mis-configuring sshd_config is one of the most common self-inflicted SSH disasters. The three-step sequence above prevents it.

Checking negotiated algorithms on an active connection

After hardening, verify what your actual SSH session negotiated:

# On the client, while connected
ssh -v user@host 2>&1 | grep -E '(cipher|MAC|kex)'

# Query algorithms the server supports without connecting
nmap --script ssh2-enum-algos -p 22 host

The -v output shows lines like:

kex: curve25519-sha256
server->client cipher: [email protected] MAC: <implicit>

<implicit> for the MAC means an AEAD cipher was negotiated (chacha20-poly1305 or aes-gcm), which is correct — no separate MAC is needed.

Client-side hardening

The same algorithm directives apply to your SSH client config at ~/.ssh/config:

Host *
  Ciphers [email protected],[email protected]
  MACs [email protected],[email protected]
  KexAlgorithms [email protected],curve25519-sha256
  HostKeyAlgorithms ssh-ed25519,rsa-sha2-512

Client-side hardening is worth doing independently of the server — it protects connections to servers you do not control and prevents your client from silently downgrading to a weaker algorithm when connecting to a legacy host.