OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
⌁

sshd Validator

Review SSH hardening controls
Input
Result1 findings
  • ✓No critical issue detected

Introduction

The sshd Validator reads a paste of sshd_config and checks five controls that are the most common causes of weak SSH posture: root login, empty passwords, password authentication, authentication retries and X11 forwarding.

The goal is not to enforce one ideology of SSH — it is to surface settings that, combined, determine whether an attacker can brute-force, or a legitimate user can lock themselves out.

Objective

  • Detect PermitRootLogin values that allow direct root login.
  • Detect PermitEmptyPasswords enabled, which permits passwordless accounts.
  • Warn when PasswordAuthentication remains enabled, so key-based access is recommended.
  • Flag MaxAuthTries above 4 and X11Forwarding enabled without a stated need.

Inputs

  • A paste of /etc/ssh/sshd_config (or sshd -T output).
  • Comment lines and blank lines are ignored; the first value for each key wins.

How it works

The tool parses each line into a key and value (case-insensitive), keeping the first occurrence of each key, which mirrors how sshd applies its defaults file.

It then compares each relevant key against the hardened expectation: permitrootlogin must be no, permitemptypasswords must be no, passwordauthentication should be no, maxauthtries must be 4 or fewer, and x11forwarding should be no.

Root login and empty passwords are treated as high severity because they remove the two main barriers to remote compromise. The remaining controls are warnings because their ideal value depends on your environment.

Testable example

Try it — the analysis runs locally in your browser.

Example

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 4
X11Forwarding no

Expected output

PermitRootLogin no — OK.
PermitEmptyPasswords no — OK.
PasswordAuthentication no — OK.
MaxAuthTries 4 — OK.
X11Forwarding no — OK.
Result: no critical issue detected.

Reading the output

  • A high finding means a setting actively weakens the system; fix it after confirming your access path (a sudo-capable user with a working key).
  • A warning is a recommendation — for example, disabling password authentication is only safe once key-based login is verified.
  • Always test with a second SSH session open before reloading sshd: systemctl reload ssh (or service ssh reload).

Risks

  • Disabling password authentication while no key is configured can lock you out of the server.
  • PermitRootLogin yes invites targeted brute force on the highest-value account on the machine.
  • Changing sshd_config without a second session open is the classic way to lose remote access.

Limitations

  • The tool reads pasted text only; it does not read your real configuration file.
  • It checks a handful of controls, not a complete SSH audit.
  • It cannot detect misconfigured authentication methods, weak host keys or SSH agent issues.

Official references

FAQ

Is disabling password authentication always right?

For internet-facing servers, almost always — but only after you have verified key-based login from a second session. On some managed environments you may be required to keep password auth for a bastion.

What is a safe MaxAuthTries value?

CIS guidance recommends 4 or fewer. Lower values slow down brute force but can also annoy legitimate users with misconfigured agents.

Does this check use my real sshd_config?

No — only the text you paste. The real source of truth is /etc/ssh/sshd_config plus any files under /etc/ssh/sshd_config.d/, which you can combine with sshd -T.