Skip to content

SSH Config Checker

Paste sshd_config or sshd -T output to find password logins, root login, weak ciphers and other risky settings, with a ready-made fix.

Runs in your browser

Best: paste the output of sudo sshd -T, which shows the settings sshd really uses after every included file. Or paste /etc/ssh/sshd_config. It’s checked in your browser and never sent anywhere.

How to use the SSH config checker

  1. On your server, run sudo sshd -T and paste the output above. If you can’t, paste /etc/ssh/sshd_config instead.
  2. Read the findings, most serious first. Each one says what the setting does, why it matters and what to change it to.
  3. Copy the generated file to /etc/ssh/sshd_config.d/00-hardening.conf, check it with sudo sshd -t, and reload SSH. Keep your current session open and test a new login in a second terminal before you close it.

Why sshd -T, not the config file

sshd uses the first value it reads for most settings. On Ubuntu and Debian the main file starts with Include /etc/ssh/sshd_config.d/*.conf, so a line in an included file beats the same line further down in sshd_config. Cloud images often ship a file such as 50-cloud-init.conf that sets PasswordAuthentication yes, which is why “I set it to no and passwords still work” is such a common problem. sshd -T prints the final result after all of that, so it’s the reliable thing to check. For the same reason, the fix is written as 00-hardening.conf: it’s read first, so its values win.

The settings that matter most

  • PasswordAuthentication no: bots try passwords on every public SSH server, all day. With keys only, there’s nothing to guess. Make sure your key works first; our guide to disabling SSH password login walks through it.
  • KbdInteractiveAuthentication no: with PAM on, this is a second way to type a password, even when PasswordAuthentication is off.
  • PermitRootLogin no: log in as your own user and use sudo, so every action is tied to a person and root can’t be attacked directly.
  • Modern algorithms: current OpenSSH versions already choose safe ciphers, MACs and key exchange by default. Old guides added lines that bring back weak ones; deleting those lines is usually the best fix.

Changing the port

Moving SSH off port 22 reduces log noise but doesn’t stop a determined attacker. If you do it, allow the new port in your firewall first (the UFW Rule Builder helps), and note that on Ubuntu 22.10 and later SSH starts through ssh.socket: after changing Port, run sudo systemctl daemon-reload and sudo systemctl restart ssh.socket. An even better option is to keep SSH off the public internet entirely with SSH over Tailscale.

If you get locked out

Every major VPS provider has a web console that works without SSH. Log in there, remove or fix the file in /etc/ssh/sshd_config.d/, and reload SSH. The same applies to firewall mistakes; see locked out of a VPS by UFW.