Skip to content

Linux

sshd_config safe defaults

Learn which sshd_config settings matter and how to apply them without locking yourself out.

Updated Aug 29, 20263 min read11 reads
sshd_config safe defaults
Safe sshd_config defaults after key-based login works

Safe defaults for sshd_config mean turning off password logins once your SSH keys work, limiting root sign-in, and testing the file before you reload. On a LogicWeb VPS you have root, so these edits are yours to make with care. Keep one working session open the whole time so a bad change cannot lock you out of the server.

Settings that actually matter

After key-based login works for your normal account, set PasswordAuthentication no. That stops password guessing against the SSH daemon. Set PermitRootLogin no, or use prohibit-password if you still need a break-glass key on root. AllowUsers can list only the accounts that should connect over SSH. ListenAddress can bind the service to addresses that should accept SSH when the box has more than one.

Do not set UsePAM no only because an old blog said so, unless you can explain which PAM stack you are replacing. Many setups still need PAM for modules such as two-factor authentication. A hardened gist from the internet does not know your network or which features you still rely on, including the SFTP subsystem and DNS for hostnames in AllowUsers.

Test the config before you reload

The usual trap is a syntax error, a reload, and your only session dying at once. Keep a session open while you edit the file. Run sshd -t first so the daemon parses the config and exits nonzero on a typo.

bash
sshd -t && systemctl reload ssh

Only reload after sshd -t succeeds with no errors. The unit name is ssh on Debian and sshd on RHEL, so use systemctl reload sshd when that is what list-units shows. Reload is not the same as restart. Existing sessions stay up, and new connections receive the new policy. A full restart can drop you before the new config is proven safe.

What does not replace key login

Port 22 is fine for most servers; keys are the real control. Changing the port only hides you from the noisiest scanners and does not replace turning passwords off. A login banner is not a security control. MaxAuthTries is a small nicety once stronger settings are in place. fail2ban on the port you actually use is optional spice after keys work. PermitEmptyPasswords should already be no; if a grep shows otherwise, fix that first rather than adding a banner.

Drop-in files and the effective policy

Include files under /etc/ssh/sshd_config.d/ in your mental model, because distros ship settings there. Your edit in the main file can lose to a later drop-in, or the reverse, depending on Include order. After you edit, trust sshd -T for the effective config rather than the file you remember changing.

On current Debian and RHEL images, drop-ins under sshd_config.d are normal. Run sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication' to see the live policy. If that output still shows password authentication yes, you edited the wrong file and should correct it before you rely on the change.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Was this article helpful?

Be the first to rate this article.