SSH Hardening Check
Point this audit at any host and it opens a read-only handshake to the SSH service on TCP 22, reads the version banner, and inspects the algorithms the server actually offers: the key-exchange (KEX), host-key, cipher and MAC sets. It flags weak or legacy primitives, the obsolete SSH protocol 1 (and the 1.99 fallback), and the unencrypted 'none' cipher — then returns the exact configuration changes to make. It never logs in, never brute-forces, and never sends a password; it only negotiates, reads what is advertised, and disconnects.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- The SSH version banner and detected product (e.g. OpenSSH, Dropbear) on TCP 22
- Key-exchange (KEX) algorithms offered, flagging weak SHA-1 / legacy groups (SSH_WEAK_KEX)
- Host-key algorithms, flagging weak or legacy types such as ssh-dss / 1024-bit keys (SSH_WEAK_HOSTKEY)
- Symmetric ciphers, flagging legacy 3DES / RC4 / CBC choices (SSH_WEAK_CIPHER)
- MAC algorithms, flagging MD5 and other weak/legacy MACs (SSH_WEAK_MAC)
- The 'none' cipher — a session that can be negotiated with no encryption at all (SSH_CIPHER_NONE)
- The obsolete, cryptographically broken SSH protocol 1 (SSH_PROTOCOL_1) and the SSH-1 fallback / protocol 1.99 advertisement (SSH_PROTOCOL_1_FALLBACK)
- The equivalent command — nmap -Pn -p22 --script ssh2-enum-algos,ssh-hostkey,sshv1 <host> — so you can reproduce it
How to read the result
- OK (pass): SSH answered and offers a modern, hardened algorithm set — no weak ciphers, key-exchange, host-key or MAC algorithms and no SSH-1.
- OK with 'no SSH service responded': nothing answered on port 22 — the port is closed, filtered, or SSH runs on a non-standard port; there is nothing to audit from here.
- Fail — SSH protocol 1: the server speaks the obsolete, cryptographically broken SSHv1; force protocol 2 only immediately.
- Fail — 'none' cipher: the server will negotiate an unencrypted session; remove the none cipher from the configuration.
- Warn — weak/legacy algorithm group(s): SHA-1 key-exchange, 3DES/RC4 ciphers, or MD5 MACs are still offered; modernise the Ciphers, KexAlgorithms, HostKeyAlgorithms and MACs lines.
- Warn — SSH-1 fallback (protocol 1.99): the server still advertises the SSH-1 fallback; force protocol 2 only.
- The verdict mirrors the worst finding; each evidence row (banner, kex, host-key, ciphers, macs) shows exactly what the server advertised so you can see what to remove.
Frequently asked questions
Does this audit try to log in or guess passwords?
No. It performs only the unauthenticated SSH handshake: it reads the version banner and the offered key-exchange, host-key, cipher and MAC algorithms, then disconnects. It never authenticates, never brute-forces credentials, and never sends a password — it inspects what the server advertises, nothing more.
It says my SSH is fine but I use a non-standard port — why?
The audit is fixed to TCP 22, the standard SSH port; any :port you paste is ignored. If your SSH daemon listens elsewhere, port 22 will appear closed/filtered and the audit reports there is nothing to check. Running SSH on a non-standard port is obscurity, not security, so still harden the daemon's algorithms.
Why does it flag CBC ciphers, 3DES, RC4 or SHA-1 key exchange?
Those are legacy primitives kept for old-client compatibility. RC4 and 3DES are weak ciphers, CBC-mode ciphers have known SSH weaknesses, MD5-based MACs are broken, and SHA-1 / 1024-bit (e.g. diffie-hellman-group1) key exchange is no longer considered safe. The fix is to restrict the daemon to modern algorithms (curve25519/AES-GCM/ChaCha20, ETM MACs) and drop the legacy ones.
What is the 'none' cipher and why is it critical?
Some SSH builds can offer a 'none' cipher, which negotiates a session with no encryption at all — everything, including any subsequent authentication, travels in clear text. It should never be enabled on a server; the audit raises it as a critical finding so you remove it from the cipher list.
What is the SSH-1 fallback (protocol 1.99)?
A banner of SSH-1.99 means the server still accepts the obsolete SSH protocol 1 alongside protocol 2. SSHv1 has fundamental, unfixable cryptographic flaws, so any fallback to it is a risk. Set the daemon to protocol 2 only so it stops advertising 1.99.
Is this the same engine as the Service Inspector?
Yes. The SSH audit reuses the exact read-only SSH probe the full Service Inspector runs, focused on port 22. It is the same source of truth, just scoped to one service so you get a fast, SSH-specific verdict and the precise hardening fixes.