Free tools

SSH config checker

Paste your effective SSH server configuration and get a plain-English review of what is weak and why, with the fix for each finding. No signup.

Runs in your browser. What you paste or open is read by this page and goes nowhere: it is not uploaded, not stored and not sent to analytics. The page counts one anonymous “tool used” event with the tool’s name and nothing else. You can check by opening your browser’s network tab, or by going offline after the page loads.
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.

What it checks

23 directives, each judged only when it is present: authentication (passwords, keyboard-interactive with PAM, keys, empty passwords, host-based and rhosts trust, root login), session exposure (X11, TCP and tunnel forwarding, gateway ports, idle timeouts), brute-force limits (MaxAuthTries, LoginGraceTime), evidence (LogLevel, StrictModes), and algorithms OpenSSH no longer enables by default (CBC and RC4 ciphers, MD5 and truncated MACs, SHA-1 key exchange, ssh-rsa signatures). AllowUsers, AllowGroups and AuthenticationMethods are reported for review when present.

A finding is only as good as the input. With sshd -T output it reflects what OpenSSH enforces. With a raw file it reflects that file alone, read the way sshd reads it: the first value for a keyword wins and settings inside Match blocks are not global.

Related

auth.log analyzerWho is trying to log in, and did anyone get infail2ban config checkerIs the jail that bans them configured to workSSH hardening checklistEvery setting, with how to apply it safelyWhat is an SSH brute-force attack?How guessing works and what stops itSSH brute force protection in SecAIDetection and automatic blocking

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.

How do I check the settings a Match block gives one user or address?

Ask sshd to evaluate the match for that connection: sudo sshd -T -C user=deploy,host=example.com,addr=192.0.2.10 prints the effective settings for that user arriving from that address. Paste that output to check it. A raw file is read globally only: settings inside Match blocks are listed but not judged, because they apply only when the match is true.

What is the most important SSH setting to change?

PasswordAuthentication no, after confirming key-based login works in a separate session you keep open, together with KbdInteractiveAuthentication no, because with PAM enabled keyboard-interactive can still ask for the password. 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.