SSH Algorithm Policy Checker
Check SSH algorithm evidence against modern, compatibility, or legacy-exception policies with scorecard findings and config patch cues.| Category | Algorithm | State | Severity | Evidence | Recommended action | Copy |
|---|---|---|---|---|---|---|
| {{ row.categoryLabel }} | {{ row.algorithm }} | {{ row.state }} | {{ row.severity }} | {{ row.evidence }} | {{ row.action }} |
| Priority | Directive | Finding | Fix | Patch cue | Copy |
|---|---|---|---|---|---|
| {{ row.priority }} | {{ row.directive }} | {{ row.finding }} | {{ row.fix }} | {{ row.patchCue }} |
| Category | Directive | Count | Preferred first | Weak or legacy | Unknown | Copy |
|---|---|---|---|---|---|---|
| {{ row.categoryLabel }} | {{ row.directive }} | {{ row.count }} | {{ row.preferredFirst }} | {{ row.weakLegacy }} | {{ row.unknown }} |
{{ result.configPatch }}
Introduction:
SSH security depends on more than the port being reachable and the host key being known. During connection setup, the client and server negotiate a key exchange method, a host key signature algorithm, a cipher, and a message authentication code. If one of those categories contains only obsolete choices, the session may fail. If legacy choices remain enabled for convenience, older clients may connect while modern clients inherit avoidable cryptographic risk.
Algorithm policy work is usually a compatibility problem and a security problem at the same time. A hardened server may prefer Curve25519 or hybrid key exchange, Ed25519 or RSA SHA-2 host keys, AEAD ciphers, and encrypt-then-MAC variants. A legacy appliance may still require SHA-1 key exchange, CBC ciphers, DSA, or ssh-rsa. The review question is not only whether a name appears in a config file, but whether that name should be kept, removed, or time-boxed for a specific target.
SSH evidence arrives in several shapes. A server config might list KexAlgorithms, Ciphers, MACs, and HostKeyAlgorithms. A client config may also include PubkeyAcceptedAlgorithms. A network scan such as ssh2-enum-algos reports what the server offered, while an audit report may classify the same names with warnings. Each source answers a slightly different question, so the evidence type matters.
Modern OpenSSH changes defaults over time. Algorithms that were once common, such as DSA host keys, RSA/SHA-1 signatures, SHA-1 key exchange, CBC ciphers, 3DES, RC4, MD5 MACs, and truncated MACs, may now be omitted from defaults, discouraged, or left only for exceptional compatibility. The safest review records both the weak name and the reason it is still needed, then sets a removal window if business reality prevents immediate cleanup.
| Category | What it protects | Review cue |
|---|---|---|
| Key exchange | How the session keys are established. | Prefer Curve25519, strong finite-field SHA-2 groups, or hybrid KEX where supported. |
| Host key | How the server proves its identity. | Prefer Ed25519 and RSA SHA-2 over DSA or RSA/SHA-1. |
| Cipher | How session traffic is encrypted. | Prefer AEAD and CTR families over CBC, 3DES, RC4, or none. |
| MAC | How message integrity is checked. | Prefer SHA-2 and encrypt-then-MAC variants over MD5, RIPEMD, or truncated hashes. |
How to Use This Tool:
Use the checker when you have SSH config text, scan output, or a copied algorithm list and need a policy scorecard plus a remediation cue.
- Set Target label to the server, client fleet, ticket, or audit slice represented by the evidence.
- Choose Evidence type. Auto-detect accepts OpenSSH directives, Nmap
ssh2-enum-algosoutput, ssh-audit-style rows, and named category lists. - Select Policy baseline. Modern hardening, balanced server policy, compatibility review, client acceptance, and legacy exception profiles use different preferred lists.
- Paste the SSH evidence or load a sample. The source status should show parsed lines and active algorithm count.
- Use Review mode to decide whether legacy warnings stay warnings, become blockers, or remain advisory.
- Leave Check strict KEX marker enabled when scan evidence might reveal Terrapin-sensitive combinations without a strict key-exchange marker.
- Read Policy Scorecard first, then move to Remediation Queue, Algorithm Inventory, Algorithm Risk Mix, and Config Patch.
When no algorithm names parse, use a more explicit source format such as one directive per line or an Nmap section with category headings. Missing categories should be treated as incomplete evidence, not as passing categories.
Interpreting Results:
The summary score and grade are a triage view. An A means the parsed evidence aligns well with the selected policy. A lower grade means the scorecard contains blockers, warnings, or unknown names. A single deprecated algorithm can matter more than several acceptable compatibility fallbacks because SSH negotiation only needs one mutually supported weak option to become relevant for an older peer.
- Policy Scorecard names every parsed algorithm, its category, state, severity, evidence note, and recommended action.
- Remediation Queue condenses category problems into patchable directives.
- Algorithm Inventory shows count, preferred first algorithm, weak or legacy names, and unknown names by category.
- Config Patch is a starting point, not an automatic deployment artifact. Test it with
sshd -Tor the matching client config before rollout.
A warning does not always mean immediate removal is possible. For legacy appliances, choose a time-boxed legacy exception only when there is a documented compatibility need and a replacement plan.
Technical Details:
SSH algorithm negotiation chooses one compatible algorithm from each category. The configured order matters because clients and servers usually try preferred names first, but the presence of a weak fallback can still expose risk when an old peer negotiates it. Policy review therefore needs both inventory coverage and a severity judgment for each active name.
The checker classifies algorithm names into recommended, acceptable, legacy, weak, deprecated, unknown, removed, or missing evidence states. Known deprecated and weak names become blockers. Legacy names usually become warnings, but strict review and modern or client-focused profiles can promote them to blockers. Unknown names can be informational, warnings, or blockers depending on the selected unknown-policy setting.
Formula Core:
The grade is derived from a simple penalty score after the parsed rows are classified.
| Item | Meaning | Effect |
|---|---|---|
B |
Blocker rows | Each blocker subtracts 16 points. |
W |
Warning rows | Each warning subtracts 7 points. |
U |
Unknown rows | Each unknown subtracts 3 points unless configured as informational or blocking. |
| Grade | A, B, C, D, or F | A starts at 92, B at 82, C at 70, D at 55, and lower scores are F. |
Rule Core:
| Tier | Typical examples | Default action |
|---|---|---|
| Recommended | Curve25519 or hybrid KEX, Ed25519 host keys, AEAD ciphers, SHA-2 EtM MACs. | Keep near the front of the preference list. |
| Acceptable | RSA SHA-2, ECDSA, CTR ciphers, strong SHA-2 finite-field KEX. | Keep as compatibility fallback after preferred names. |
| Legacy | ssh-rsa, diffie-hellman-group14-sha1, CBC ciphers, SHA-1 MACs. |
Warn or block depending on profile and review mode. |
| Deprecated or weak | DSA, group1 SHA-1, 3DES, RC4, MD5 MACs, none. |
Remove before production use. |
| Unknown | Vendor names or new algorithms not in the local catalog. | Check vendor and OpenSSH support before keeping or removing. |
The strict key-exchange marker check is separate from ordinary algorithm tiering. When evidence includes Terrapin-sensitive cipher or MAC families, the checker looks for an OpenSSH strict-KEX marker in scan-style evidence and asks for version or vendor confirmation when the marker is missing.
Limitations and Privacy Notes:
The checker reads pasted evidence in the browser and does not scan a host, open an SSH connection, or verify the running daemon. A config file can also differ from the effective runtime policy after includes, match blocks, distro patches, crypto policy, or daemon reload state.
- Confirm server-side policy with
sshd -Ton the target host when possible. - Confirm remote offers with a scan such as
ssh2-enum-algoswhen the network-facing behavior matters. - Test the generated patch in a maintenance window and keep an alternate access path before changing SSH on remote infrastructure.
Worked Examples:
Nmap evidence with mixed policy
An ssh2-enum-algos report that includes curve25519-sha256, diffie-hellman-group14-sha1, ssh-ed25519, ssh-rsa, aes128-cbc, and hmac-sha1 should produce a scorecard with modern keep rows plus warnings or blockers for SHA-1, CBC, and RSA/SHA-1 compatibility. Algorithm Risk Mix should show risk concentrated in KEX, host key, cipher, and MAC categories.
Hardened server baseline
A server config using Curve25519 or hybrid KEX, Ed25519 or RSA SHA-2 host keys, GCM or Chacha20-Poly1305 ciphers, and SHA-2 EtM MACs should score near the top under Balanced server policy. The Config Patch can still be useful as a reference order for future cleanup.
Missing category evidence
If only Ciphers are pasted, the checker can review cipher names but will warn that key exchange, host key, and MAC evidence is missing. Treat those rows as incomplete evidence and paste the remaining directives before approving the target.
FAQ:
Can I paste Nmap output directly?
Yes. Choose Auto-detect or Nmap ssh2-enum-algos. The parser reads category headings such as kex_algorithms, server_host_key_algorithms, encryption_algorithms, and mac_algorithms.
Why is ssh-rsa treated as legacy?
ssh-rsa means RSA signatures with SHA-1, not all RSA keys. Prefer rsa-sha2-256, rsa-sha2-512, or Ed25519 host keys where clients support them.
Should unknown algorithms be blocked?
Use Warn on unknown for ordinary review, Block unknown for strict launch gates, and informational treatment only when vendor documentation or fleet testing already explains the name.
Does the generated config patch preserve every compatibility exception?
No. The patch follows the selected baseline and should be tested against the target clients or servers. Keep exception windows explicit when older devices still need a legacy algorithm.
Glossary:
- KEX
- Key exchange, the negotiation step that establishes shared session keys.
- Host key algorithm
- The signature family used by the server to prove its identity to the client.
- AEAD
- Authenticated encryption with associated data, a cipher design that combines confidentiality and integrity checks.
- EtM
- Encrypt-then-MAC, a MAC construction that authenticates ciphertext rather than plaintext.
- Terrapin
- An SSH prefix-truncation attack class mitigated by strict key exchange support in modern SSH releases.
References:
- OpenSSH legacy options, OpenSSH.
- OpenSSH 9.6 release notes, OpenSSH, 2023.
- ssh2-enum-algos NSE script, Nmap.
- OpenSSH guidelines, Mozilla.