sshd_config Analyzer: Grade and Harden Your SSH Server Config

1. On your server, print the config: cat /etc/ssh/sshd_config. Copy the output.
2. Paste it into the box above. The review runs as you type, in your browser, and nothing is uploaded.
3. Read the findings worst-first. Each one shows the directive, the line it is on, what it is set to now, and what it should be.
4. If the tool warns that an Include may override your settings, run sudo sshd -T on the server and paste that output instead. It resolves every included file and Match block, so the answer is definitive.
5. Switch to the Hardening patch tab, apply the safe lines, then verify with sudo sshd -t before reloading.

Almost every configuration format on a Linux server uses the last value it reads. sshd_config does the opposite.The manual is explicit: "unless noted otherwise, for each keyword, the first obtained value will be used".

So a file containing PasswordAuthentication yes on line 20 and PasswordAuthentication no on line 60 accepts passwords. sshd prints no warning, the second line is simply dead, and reading the file top to bottom gives you the wrong answer unless you know the rule. This tool flags every duplicate and tells you which line actually won.

A few directives are exceptions and accumulate instead of overriding: HostKey, ListenAddress, Port, AllowUsers, AllowGroups, AcceptEnv, Include and Subsystem. Reporting those as duplicates is a false positive, so this tool does not.

This is the most common way a hardened-looking config is not hardened at all. Ubuntu 22.04 and later ship an sshd_config whose first line is Include /etc/ssh/sshd_config.d/*.conf.

Combine that with first-value-wins and the consequence is severe: anything in that directory is read first and therefore overrides the whole main file. On a cloud image, cloud-init writes /etc/ssh/sshd_config.d/50-cloud-init.conf containing PasswordAuthentication yes. You can set PasswordAuthentication no in the main config, restart sshd, and still be accepting passwords.

When this tool sees an Includeahead of a directive it marks that finding "may be overridden" rather than quietly passing it. To settle it, run sudo sshd -T and paste the output: that is the fully resolved configuration sshd is actually running, with every include and default filled in.

PasswordAuthentication nois the single most valuable line in an SSH config and the single easiest way to lose a server. If key login is not already working, applying it ends your access the moment sshd reloads, and the only way back is your provider's console or a rescue boot.

That is why the hardening patch here is split in two. Everything that cannot end your session is in one block. PasswordAuthentication, PermitRootLogin and the allow-list directives are in a separate block behind a warning, because each of them can.

The safe order is always the same: open a second terminal, log in with your key, confirm it does not ask for a password, and keep your first session open the entire time. Then apply, run sudo sshd -t to check the syntax, and sudo systemctl reload ssh rather than restart so existing sessions survive.

One more trap: PasswordAuthentication no on its own does not disable password login. PAM can still prompt through keyboard-interactive, so you need KbdInteractiveAuthentication no as well. The patch includes it. The exception is a server using PAM-based MFA such as Google Authenticator, where that line would lock you out instead.

A Match block applies its directives only to connections meeting a condition, and everything after it stays inside that block until the next Match or the end of the file. That makes it easy to write a global policy and then quietly undo it:

PermitRootLogin no at the top, then Match User deploy followed by PermitRootLogin yes three hundred lines down. The global setting looks right in a review, and root login is still possible.

This tool evaluates Match blocks separately from global scope. A weak directive inside a Match block is never reported as your global setting, and a Match block that re-enables something the global scope disabled gets its own finding.

This tool reads text. It is honest about the limits of that. It cannot tell you whether a key in authorized_keys still belongs to someone who works here, whether an account has a blank password, who is in the sudo group, or whether an old employee still has access to three of your servers. None of that is in sshd_config.

Those checks need the running machine. The SSH and Access checklist lists all eleven of them as plain shell commands you can paste into a terminal, and the fix pages cover what to do with each result. CtrlOps runs the whole set over SSH across every server you manage and hands back a hardening score and a PDF, but the checklist works perfectly well on its own.