Algorithm reference

Every one of the 77 algorithms this tool rates, what it thinks, and why. Sorted worst first, because the reason to open a page like this is usually to find out what to remove.

Key exchange (19)

How the two sides agree on a shared secret without ever sending it. This is where forward secrecy comes from, and where post-quantum protection is being added — a recorded session is decryptable later if and only if this step was weak.

Algorithm	Verdict
`diffie-hellman-group1-sha1`	broken 1024-bit fixed MODP group and SHA-1. Precomputation against this exact prime is within reach of a state actor (Logjam, 2015). Disable it
`gss-group1-sha1-`	broken GSSAPI key exchange over the 1024-bit group with SHA-1
`rsa1024-sha1`	broken 1024-bit RSA key transport with SHA-1. No forward secrecy at all
`diffie-hellman-group-exchange-sha1`	weak SHA-1 in the key exchange hash
`diffie-hellman-group14-sha1`	weak SHA-1 in the key exchange hash. The 2048-bit group is fine; the hash is not, and it is trivially avoidable
`rsa2048-sha256`	weak RSA key transport. No forward secrecy: recovering the host key later decrypts every session recorded before that
`curve25519-sha256`	good X25519 ECDH. Fast, constant-time, no NIST curve constants. The sane baseline
`curve25519-sha256@libssh.org`	good X25519 ECDH under its pre-standard name. Identical to curve25519-sha256
`diffie-hellman-group-exchange-sha256`	good negotiated MODP group with SHA-256. Strength depends on the group the server offers
`diffie-hellman-group14-sha256`	good 2048-bit MODP group with SHA-256. The floor of acceptable finite-field DH
`diffie-hellman-group15-sha512`	good 3072-bit MODP group with SHA-512
`diffie-hellman-group16-sha512`	good 4096-bit MODP group with SHA-512
`diffie-hellman-group18-sha512`	good 8192-bit MODP group with SHA-512. Very conservative, very slow
`ecdh-sha2-nistp256`	good ECDH over NIST P-256. Sound, but the curve constants have unexplained provenance and the implementations are harder to make constant-time
`ecdh-sha2-nistp384`	good ECDH over NIST P-384. Same caveat as P-256, larger group
`ecdh-sha2-nistp521`	good ECDH over NIST P-521. Same caveat as P-256, larger group
`mlkem768x25519-sha256`	excellent post-quantum hybrid (ML-KEM-768 + X25519). The NIST-standardised KEM; protects today's traffic against a future quantum attacker
`sntrup761x25519-sha512`	excellent post-quantum hybrid (Streamlined NTRU Prime + X25519). OpenSSH's default since 9.0
`sntrup761x25519-sha512@openssh.com`	excellent post-quantum hybrid (Streamlined NTRU Prime + X25519). OpenSSH's default since 9.0

Ciphers (20)

The symmetric encryption applied to every byte after the handshake. The modern ones are AEAD: they authenticate as well as encrypt, so there is no separate MAC to get wrong.

Algorithm	Verdict
`3des-cbc`	broken 64-bit block cipher, ~112-bit effective key, CBC mode (Sweet32). Deprecated by NIST
`3des-ctr`	broken Triple-DES. 64-bit block, ~112-bit effective key
`arcfour`	broken RC4. Biased keystream, practically broken
`arcfour128`	broken RC4 with 1536 bytes discarded. Still RC4
`arcfour256`	broken RC4 with 1536 bytes discarded. Still RC4
`blowfish-cbc`	broken 64-bit block cipher in CBC mode. Birthday-bound collisions after ~32 GB on one key (Sweet32)
`cast128-cbc`	broken 64-bit block cipher in CBC mode (Sweet32)
`none`	broken no encryption at all
`rijndael-cbc@lysator.liu.se`	broken Pre-standard AES naming in CBC mode. Its presence means a very old client
`aes128-cbc`	weak CBC mode — see aes256-cbc
`aes192-cbc`	weak CBC mode — see aes256-cbc
`aes256-cbc`	weak CBC mode. SSH's encrypt-and-MAC construction over CBC enabled a plaintext-recovery attack (CPNI-957037, 2008); CTR or GCM instead
`aes128-ctr`	good AES-128 in counter mode. Pair it with an ETM MAC
`aes192-ctr`	good AES-192 in counter mode. Pair it with an ETM MAC
`aes256-ctr`	good AES-256 in counter mode. Not authenticated by itself, so it leans on the MAC — pair it with an ETM MAC
`aes128-gcm`	excellent AES-128 in GCM (RFC 5647 naming)
`aes128-gcm@openssh.com`	excellent AES-128 in GCM. AEAD, hardware-accelerated on anything modern
`aes256-gcm`	excellent AES-256 in GCM (RFC 5647 naming)
`aes256-gcm@openssh.com`	excellent AES-256 in GCM. AEAD, hardware-accelerated on anything modern
`chacha20-poly1305@openssh.com`	excellent AEAD. Constant-time in software, no timing side channel on hosts without AES instructions

MACs (15)

Integrity protection for ciphers that do not authenticate on their own. The -etm suffix — encrypt-then-MAC — is the axis that matters: without it the receiver must decrypt attacker-chosen bytes before it can check the tag.

Algorithm	Verdict
`hmac-md5`	broken MD5. Collision-broken hash in an encrypt-and-MAC construction
`hmac-md5-96`	broken MD5 truncated to 96 bits
`none`	broken no integrity protection at all
`hmac-ripemd160`	weak RIPEMD-160. Obsolete, little analysed
`hmac-sha1`	weak SHA-1, and encrypt-and-MAC. Still collision-resistant enough for HMAC in practice, but there is no reason to keep it
`hmac-sha1-96`	weak SHA-1 truncated to 96 bits, encrypt-and-MAC
`hmac-sha1-etm@openssh.com`	weak encrypt-then-MAC, but the hash is SHA-1
`umac-64@openssh.com`	weak 64-bit tag and encrypt-and-MAC
`hmac-sha2-256`	good HMAC-SHA-256, but encrypt-and-MAC. Prefer the -etm variant
`hmac-sha2-512`	good HMAC-SHA-512, but encrypt-and-MAC: the receiver decrypts before authenticating. Prefer the -etm variant
`umac-128@openssh.com`	good UMAC-128, encrypt-and-MAC. Prefer the -etm variant
`umac-64-etm@openssh.com`	good UMAC-64, encrypt-then-MAC. A 64-bit tag is small; prefer the 128-bit variant
`hmac-sha2-256-etm@openssh.com`	excellent HMAC-SHA-256, encrypt-then-MAC
`hmac-sha2-512-etm@openssh.com`	excellent HMAC-SHA-512, encrypt-then-MAC. The tag is checked before anything is decrypted
`umac-128-etm@openssh.com`	excellent UMAC-128, encrypt-then-MAC. Very fast

Host key algorithms (20)

How the server proves it is the server. Note these name the SIGNATURE algorithm, not the key: ssh-rsa and rsa-sha2-512 can be the very same RSA key, differing only in the hash used to sign.

Algorithm	Verdict
`ssh-dss`	broken DSA, fixed at 1024 bits, and fatally sensitive to nonce reuse. Removed from OpenSSH entirely in 10.0
`ssh-dss-cert-v01@openssh.com`	broken DSA certificate. See ssh-dss
`ssh-rsa`	weak RSA signed with SHA-1. OpenSSH disabled this by default in 9.0; the key is fine, the signature hash is not
`ssh-rsa-cert-v01@openssh.com`	weak RSA certificate signed with SHA-1
`ecdsa-sha2-nistp256`	good ECDSA over NIST P-256. Sound, but ECDSA needs a unique nonce per signature and implementations have leaked keys by getting that wrong
`ecdsa-sha2-nistp256-cert-v01@openssh.com`	good ECDSA P-256 host certificate
`ecdsa-sha2-nistp384`	good ECDSA over NIST P-384
`ecdsa-sha2-nistp384-cert-v01@openssh.com`	good ECDSA P-384 host certificate
`ecdsa-sha2-nistp521`	good ECDSA over NIST P-521
`ecdsa-sha2-nistp521-cert-v01@openssh.com`	good ECDSA P-521 host certificate
`rsa-sha2-256`	good RSA signed with SHA-256
`rsa-sha2-256-cert-v01@openssh.com`	good RSA host certificate signed with SHA-256
`rsa-sha2-512`	good RSA signed with SHA-512
`rsa-sha2-512-cert-v01@openssh.com`	good RSA host certificate signed with SHA-512
`sk-ecdsa-sha2-nistp256-cert-v01@openssh.com`	good ECDSA P-256 FIDO2 certificate
`sk-ecdsa-sha2-nistp256@openssh.com`	good ECDSA P-256 backed by a FIDO2 authenticator
`sk-ssh-ed25519-cert-v01@openssh.com`	excellent Ed25519 FIDO2 certificate
`sk-ssh-ed25519@openssh.com`	excellent Ed25519 backed by a FIDO2 authenticator
`ssh-ed25519`	excellent Ed25519. Small, fast, constant-time, no parameter choices to get wrong
`ssh-ed25519-cert-v01@openssh.com`	excellent Ed25519 host certificate — the host's key is vouched for by a CA, so clients need no known_hosts entry

Compression (3)

Almost always the right answer is none. The interesting case is `zlib` versus `zlib@openssh.com`: the same algorithm, but the second only switches on after authentication.

Algorithm	Verdict
`zlib`	weak zlib enabled BEFORE authentication, so it compresses attacker-influenced data alongside secrets
`none`	good no compression. The right default: compression before encryption leaks plaintext length
`zlib@openssh.com`	good zlib, enabled only AFTER authentication. The delay is what makes it safe

How to read the ratings

excellent — what you should be using. No known weakness and no reason to avoid it.
good — sound. Often a slightly older or slower choice, or one with a sharper edge if implemented carelessly.
weak — not broken today, but with a known flaw, an obsolete hash, or a better replacement that costs nothing. Remove when convenient.
broken — a practical attack exists, or the parameters are too small. Remove now.
unknown — not in this catalogue. It may be brand new, vendor-specific, or a typo. Deliberately not rated as weak: post-quantum names have churned twice in three years, and a tool that condemns tomorrow's algorithm because it shipped yesterday is worse than one that admits it does not know.

These are judgements, not facts, and they are checkable — every verdict says why, so you can disagree with the reasoning rather than the score. When in doubt, prefer what your OpenSSH ships with by default: those defaults are chosen carefully, and the most common way to end up with weak cryptography is to override them.