SSH Server Config Auditor
Paste your sshd_config or upload the file. The audit runs entirely in your browser — nothing is uploaded — and you get a score, per-line findings, and a hardened config to download.
sshd_config is the file that decides who can log in to your server and how: root login, password authentication, which ciphers and key-exchange algorithms are offered, and how long idle sessions linger. This tool audits your sshd_config in the browser against the Mozilla OpenSSH guidelines and the OpenSSH 10.6 defaults, scores it 0–100, lists every finding by line, and builds a hardened config you can download. It understands first-match semantics, Match blocks and Include lines, so a clean first page cannot hide a weak Match block. If you generate keys, use the SSH key suite; to check whether a password has leaked, use the password breach check; and if a secret ever lands in a config, the leaked secret scanner finds it. The companion article how to harden your SSH server config explains the same settings in prose.
Baseline: Mozilla OpenSSH guidelines + OpenSSH 10.6 defaults, verified 2026-11-13.
Last updated:
🔒 Your config is parsed in your browser and never leaves your device. No account, no upload, no server call.
What happens to the config you paste
Nothing leaves your browser. The config is parsed locally by JavaScript on this page: no upload, no server call, no storage, no account. That matters because a server config is infrastructure detail — hostnames, usernames, allowed users and ports — and it should never be pasted into a chat or a server-side checker. Closing the page discards it.
What this score does NOT prove
A clean score is not proof of security. It means this file, against this baseline, has no flagged directive — a weak key, a leaked credential, an unpatched sshd or a missing firewall can still undo it.
A bad score is not proof of a breach. It is a list of settings to change, in priority order — fix the errors first, then the warnings.
Baselines move. This audit is dated 2026-11-13 against the Mozilla OpenSSH guidelines and OpenSSH 10.6 defaults; an algorithm that is modern today may be deprecated tomorrow. Re-audit when you upgrade sshd.
How the score is built
Each error costs 15 points and each warning 7; notes cost nothing. Findings inside Match blocks are conditional — they apply only to sessions matching the block, so they are listed but do not lower the score. The four bands are deliberately coarse: 80–100 is high, 60–79 moderate, 40–59 low, and 0–39 poor — a finer scale would pretend to a precision a config audit does not have.
How the audit works
sshd reads each directive once: for every keyword, the first value it meets wins, and later duplicates are silently ignored. This tool cites the effective line and flags the shadowed duplicate, so a "fixed" line below the first one does not fool it. A directive that is absent is audited against its OpenSSH default — absence is never treated as a pass when the default itself is permissive, which is why PasswordAuthentication is the most common finding on untouched configs.
Directives inside a Match block apply only to sessions matching its criteria, so findings there are conditional: they are listed with the block they live in, but they do not lower the score. Include lines are flagged as not followed — included files are never read, so a directive that lives only in an included file is invisible to this audit. For a complete audit, paste the merged config (sshd -T prints the effective configuration).
This tool reads the file, not the running server: it cannot see whether sshd is actually running this config, how strong your keys are, or whether a firewall or fail2ban guards the port. Disabling PasswordAuthentication is not sufficient on its own if PAM can still accept passwords — check KbdInteractiveAuthentication and your PAM stack too. And changing the port is obscurity, not hardening: it is noted, never scored.
Frequently asked questions
Why is PasswordAuthentication the most common finding?
Because the OpenSSH default is yes: most distributions ship password login on, and many operators never turn it off. Disabling it — and checking KbdInteractiveAuthentication and PAM, which can still accept passwords — matters far more than changing the port, which only moves the login prompt.
My config is split across Include files. Why does the audit ignore them?
This tool runs in your browser and cannot read your server’s filesystem, so Include lines are flagged as not followed rather than silently skipped. Paste the merged config instead: sshd -T prints the effective configuration with all includes resolved, and that is the file this audit is built for.
Can I drop the hardened config straight onto my server?
No — review it first. The download rewrites flagged directives to the baseline values and comments out removed or shadowed lines, but it cannot know your Match blocks, your users or your network. Test it with sshd -t, keep one session open, and test a second login before closing the first.