{{ summaryHeading }}{{ summaryPrimary }}{{ summaryLine }}{{ computation.values.status_label }} Block {{ computation.values.block_count }} Warn {{ computation.values.warn_count }}
Only algorithm names and directive coverage are evaluated; the tool does not contact or scan a host.
{{ sourceStatus }}
Auto reports the resolved source format in the verdict; explicit formats bypass detection.
Use a short label so copied findings and exported remediation stay traceable.
Use modern for maintained public services; use compatibility or an exception only for documented older peers.
The standard default preserves the selected baseline; opening Advanced without edits leaves the verdict unchanged.
Keep the default for scan output; use config-only when the paste cannot contain negotiation markers.
Review vendor documentation before copying a patch that removes an unfamiliar algorithm.
Use zero unless a named owner and removal date already exist.
days

Policy verdict

Review the decision, algorithm evidence, remediation plan, category risk mix, and generated baseline before changing a daemon or client.

{{ computation.values.status_label }}
{{ computation.values.verdict_detail }}
Grade {{ computation.values.grade }}

This browser-local review classifies supplied names; it does not prove the effective daemon policy or a negotiated connection.

Correct the evidence input before using the policy verdict.
CategoryAlgorithmSeverityEvidenceRecommended actionCopy
{{ row.category_label }}{{ row.algorithm }}{{ row.severity }}{{ row.evidence }}{{ row.action }}
PriorityDirectiveFindingFixPatch cueCopy
{{ row.priority }}{{ row.directive }}{{ row.finding }}{{ row.fix }}{{ row.patch_cue }}
 
{{ configPatch }}

Validate the generated baseline with sshd -T or ssh -G, test every required client, and keep an alternate access path before rollout.

SSH Config Snippet Generator Build OpenSSH Host blocks from CSV inventory rows with inherited defaults and warnings for risky keys, jump hosts or connection sharing.
Secure Shell (SSH) Public Key Converter Convert SSH public keys among OpenSSH, SSH2 and PEM locally while verifying key identity through matching SHA-256 fingerprints and safety checks.
Secure Shell (SSH) Public Key Extractor Extract a supported SSH public key locally, verify its SHA-256 fingerprint, and assemble a reviewed authorized_keys entry from key material.
Secure Shell (SSH) Key Fingerprint Checker Check an SSH public key locally, compare modern or legacy fingerprints, and review host-key identity warnings before trusting the key.

An SSH connection succeeds only when the client and server share acceptable choices for several stages of the transport. Key exchange establishes session keys, the host-key algorithm authenticates the server, the cipher protects confidentiality, and the message authentication code (MAC) protects integrity when the cipher does not provide it itself. One incompatible category is enough to stop negotiation.

Security policy and compatibility often pull in opposite directions. Current peers can use Curve25519 or hybrid key exchange, Ed25519 or RSA/SHA-2 signatures, authenticated-encryption ciphers, and SHA-2 Encrypt-then-MAC choices. Older appliances may still ask for SHA-1 key exchange, ssh-rsa, CBC, DSA, 3DES, RC4, or old MACs. Keeping a legacy name enabled for every connection is a much broader decision than granting one documented, time-limited exception.

Category Role in the connection Policy evidence
Key exchange (KEX)Creates the shared secret and session keysKexAlgorithms
Host keyAuthenticates the server identityHostKeyAlgorithms or accepted public-key lists
CipherEncrypts session trafficCiphers
MACAuthenticates records for non-AEAD ciphersMACs

The evidence source changes what can be concluded. Configuration text shows declared directives but may be altered by includes, host matches, distribution crypto policy, or command-line options. A scanner shows algorithms offered from one network path. An audit report adds another tool's interpretation. None of these alone proves the effective policy for every client or the algorithm a particular session negotiated.

Algorithm names also encode important distinctions. ssh-rsa means RSA signatures with SHA-1, not every RSA host key. An existing RSA key can often be used with rsa-sha2-256 or rsa-sha2-512. Similarly, a binary may recognize an old algorithm name without enabling it by default. Effective configuration and a new test connection remain the deciding evidence before a hardening change is accepted.

How to Use This Tool:

Start with evidence from one target and choose the policy that should govern that target, not the policy that happens to match the pasted list.

  1. Paste OpenSSH server or client directives, Nmap ssh2-enum-algos output, an ssh-audit report, or named lists. Pin Evidence type if automatic detection does not parse the source correctly.
  2. Enter a non-secret Target label, then choose the server, client, compatibility, or legacy-exception baseline that matches the review.
  3. Set Review mode, the strict-KEX evidence policy, and the treatment of unknown names. Use a legacy exception window from 1 to 365 days only when an approved dependency prevents immediate removal; zero means no active window.
  4. Review every Block and Warn row before looking at the letter grade. Missing categories and unknown algorithms require evidence or vendor documentation, not an assumption that the absent name is safe.
  5. Use the remediation cues to prepare a change, then validate effective configuration with sshd -T for a server or ssh -G host for a client. Test a new connection from a separate session before closing the recovery path.

Interpreting Results:

Blockers found means at least one active item crossed the selected policy's blocking rule. Review needed means no blocker was counted but warnings or unknowns remain. Policy aligned means the parsed evidence produced neither. The verdict applies to the supplied text and chosen settings, not to a live SSH service.

  • Do not let a high score overrule one critical algorithm. The score is a triage summary, while the finding row carries the release decision.
  • A missing category means no usable evidence was parsed for that category; it does not prove that the effective default is weak or strong.
  • A generated baseline is a review cue, not a ready-to-apply patch. Compare it with installed OpenSSH support and existing include or match behavior.
  • For repeated checks, keep the evidence source, baseline, review mode, unknown policy, and exception window unchanged.

Technical Details:

Policy review proceeds from text normalization to category parsing, algorithm classification, baseline-dependent disposition, and finally score and remediation output. Leading +, -, and ^ markers are retained as append, remove, and prepend evidence; explicit removals receive a pass row rather than being treated as active algorithms.

Transformation Core

Stage Exact behavior
NormalizeLine endings and case are normalized; comments and list punctuation are removed while operator prefixes are recorded.
ParseNames are assigned to KEX, host-key, cipher, or MAC categories from directives, named lists, Nmap sections, or audit rows.
ClassifyKnown names map to recommended, acceptable, legacy, weak, or deprecated entries. Uncatalogued names use family clues or remain unknown.
DecideThe baseline, review mode, exception window, strict-KEX setting, and unknown policy convert each classification to Pass, Warn, Block, or Info.

Rule Core

Weak and deprecated entries block. Legacy entries warn by default, but they block under Modern server hardening, Client acceptance policy, or Strict launch review. A Compatibility review or Time-boxed legacy exception may retain an exception-eligible legacy item as a warning when the window is greater than zero and the review is not strict. Advisory mode reduces non-critical blockers to warnings.

Tier Representative entries Default treatment
RecommendedCurve25519 or hybrid KEX, Ed25519, ChaCha20-Poly1305 or AES-GCM, SHA-2 Encrypt-then-MACPass and prefer
AcceptableSHA-2 finite-field or ECDH KEX, RSA/SHA-2 or ECDSA, AES-CTR, SHA-2 MACsPass for compatibility
Legacydiffie-hellman-group14-sha1, ssh-rsa, AES-CBC, hmac-sha1, 64-bit UMACWarn, block, or time-box according to policy
Weak or deprecatedGroup1/SHA-1, DSA, 3DES, RC4, no encryption, MD5 or truncated old MACsBlock; Advisory may downgrade a non-critical row

Unknown names follow their selected policy: informational, warning, or blocking. Missing algorithm categories always produce a warning. When Terrapin-sensitive cipher or Encrypt-then-MAC evidence is present, scan evidence without a strict-KEX marker produces a warning. Under Check scan evidence, configuration-only sources omit that finding because config text cannot prove negotiation support; Treat as config-only evidence records the missing proof as Info. A parsed strict-KEX marker passes the check.

Formula Core

The policy score starts at 100 and subtracts fixed penalties. It is clamped at zero.

S=max(0,100−16B−7W−3U)

B is the number of Block rows, W the number of Warn rows, and U the number of rows whose state is Unknown. An unknown configured to Warn contributes both the warning and unknown penalties. Grades are A for scores ≥ 92, B for 82 to 91, C for 70 to 81, D for 55 to 69, and F below 55.

The parser accepts no more than 100,000 characters, requires at least one active algorithm, and reports a separate row when a category is absent. The generated baseline orders preferred names for the chosen profile, but it does not resolve installed-version support, included configuration, or peer overlap.

Limitations and Privacy Notes:

Pasted text and locally loaded files are reviewed in the browser; the checker does not connect to the named target or apply configuration. Keep secrets, private keys, and unrelated configuration out of the evidence even though only algorithm names and surrounding lines are needed.

  • The local catalog can lag new OpenSSH or vendor-specific names, so unknown entries require authoritative review.
  • Configuration text may differ from effective output after Include, Match, and distribution policy are applied.
  • Scan output records one offered set from one path and does not prove every client-specific negotiation.

Worked Examples:

Legacy appliance exception

A scan containing diffie-hellman-group14-sha1, ssh-rsa, and aes128-cbc will not become safe merely because a compatibility profile is selected. With a documented non-zero exception window, eligible legacy rows remain warnings; critical entries such as ssh-dss, 3des-cbc, or hmac-md5 still block. The follow-up is to prove the minimum required overlap, test a replacement path, and remove the exception on schedule.

References: