Free tool

SSH config checker

Paste your effective SSH server configuration and get a plain-English review of what is weak and why. It runs entirely in your browser: nothing is uploaded, there is no signup, and no request is made to analyse your input.

Run this on your server and paste the output
sudo sshd -T

Use sshd -T rather than your sshd_config file. sshd_config uses first-occurrence-wins precedence and pulls in /etc/ssh/sshd_config.d/*.conf through Include, so a drop-in placed there by your provider image can silently override the file you edited. sshd -T asks OpenSSH to resolve all of that and print what it will actually enforce. Pasting the raw file still works, and the result is labelled as unconfirmed.

Questions

Does this tool upload my sshd_config?

No. The parser and every rule run in your browser. Nothing is sent to SecAI or anywhere else, there is no request to analyse your input, and you can confirm that by opening your browser network tab or by disconnecting from the internet after the page loads.

Why does it ask for sshd -T output instead of my sshd_config file?

Because sshd_config is often not the effective configuration. It uses first-occurrence-wins precedence and pulls in /etc/ssh/sshd_config.d/*.conf through Include, so a cloud-init drop-in that sorts before your file silently wins. Running sshd -T asks OpenSSH itself to resolve all of that and print what it will actually enforce.

What is the most important SSH setting to change?

PasswordAuthentication no, after confirming key-based login works in a separate session you keep open. It removes brute force as an attack rather than mitigating it. PermitRootLogin prohibit-password is the close second, because root is the first username every attacker tries.

Why does the checker ignore settings I have not set?

Because a directive that is absent takes OpenSSH's compiled-in default, and that default varies by version and by distribution patches. Guessing which default applies to your server would produce confident findings that might be wrong, so unset directives are simply not reported. This is also why sshd -T output gives a better result: it lists every effective value including the defaults.

Is a good sshd_config enough to secure a server?

No. It closes the most-attacked door. It says nothing about a webshell dropped in by an application vulnerability, a package with a known CVE, a new setuid binary, a change to sudoers, or a process making outbound connections somewhere new, all of which happen after a perfectly configured login.