Why disable SSH password authentication?

Because passwords can be guessed, and every public SSH server is hit by automated brute-force attempts constantly. Public-key authentication replaces a guessable secret with a cryptographic key that is not feasible to brute force, so turning passwords off shuts down the entire category of attack at once. Set up and test key-based login first, then disable passwords.

How do I not lock myself out?

Three rules: make sure key-based login already works before applying anything, keep a second SSH session open while you change the config so you can revert if the new one breaks, and run sshd -t to validate the config before reloading. The generated commands include the test step. If you have a provider web console, you also have a recovery path if something goes wrong.

Where should the config live?

On modern systems, drop it in /etc/ssh/sshd_config.d/ as a separate file (for example 99-hardening.conf) rather than editing the main sshd_config. Files in that directory are included automatically and override the defaults, which keeps your changes in one tidy, reviewable place and survives package updates to the main config.

Free tool · Runs in your browser

Harden SSH.

SSH is the front door to your server, and every public box gets its handle rattled around the clock. Pick your settings and get a hardened sshd_config — key-only auth, no root login, limited attempts — with the safe commands to apply it.

SSH port

Allow only these users (comma-separated, optional)

Disable password login (key only) Disable root login Disconnect idle sessions

Before you apply: make sure key-based login already works, and keep a second SSH session open. The commands include sshd -t to validate before reload.

99-hardening.conf

Apply commands

The door everyone tries

You don't have to imagine attacks on SSH; just tail the auth log on any public server and watch the login attempts roll in from around the world, every minute, forever. They're automated, they're relentless, and they're cheap to defeat: require a key instead of a password and the brute force has nothing to brute. Add no-root-login and a couple of limits and the front door goes from constantly-tried to effectively closed.

The config is a one-time change. The harder thing is knowing it stayed that way — that a later edit didn't re-enable passwords, that every host you run shares the same hardened baseline, that you'd notice if one drifted. That standing assurance across your fleet is what a control plane is for.

Related free tools

UFW firewall generatorLock down your server Security headers checkerGrade your headers Secrets scannerFind leaked secrets

All free tools →

Harden once. Stay hardened, provably.

Infraveil keeps the security baseline consistent across every host you own and proves it held with a tamper-evident record — so the SSH config you set today is the SSH config you have in six months.

See how it works

Get the server-hardening playbook

SSH, firewall, and the basics that stop most attacks on a box you own. No spam.