How to harden your SSH configuration safely

SSH is the front door to your server, and the first place automated attacks knock. The default settings accept passwords and root logins, which is convenient and also exactly what attackers want. A few changes to the SSH configuration make it far harder to break in. The key is to make them in the right order, and to test before you close the door behind you.

Before you start

You need three things in place first:

  1. A normal user with sudo rights. See How to create a non-root user with sudo.
  2. SSH key login that works for that user. See How to set up SSH key authentication.
  3. A second open session that stays connected while you change settings. If you break the configuration, that session is how you fix it.

If the key does not work yet, do not continue. Turning passwords off without a working key locks you out.

Where the settings live

The SSH server reads /etc/ssh/sshd_config. On recent Ubuntu versions, that file also includes any files in /etc/ssh/sshd_config.d/, and the first value found wins. So a setting in a file in that folder can override your edits to the main file. If a change does not take effect, check the folder:

sudo grep -r "PasswordAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

A neat approach is to put your own settings in a new file such as /etc/ssh/sshd_config.d/00-hardening.conf, where the 00 makes it load first.

The settings that matter

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers alex
X11Forwarding no

What they do:

  • PermitRootLogin no stops anyone logging in directly as root.
  • PasswordAuthentication no allows keys only, which removes password guessing as an attack.
  • PubkeyAuthentication yes makes sure keys are allowed.
  • KbdInteractiveAuthentication no closes a side route to passwords on some setups.
  • MaxAuthTries 3 drops a connection after three failed attempts.
  • LoginGraceTime 30 gives only 30 seconds to log in.
  • AllowUsers lists the only accounts permitted to log in over SSH. Everyone else is refused, even with a valid password.
  • X11Forwarding no turns off a graphical feature you almost certainly do not use.

Use your own username in AllowUsers, and add each person who needs access, separated by spaces.

Check before you apply

Always test the syntax first, because an error can stop SSH from starting:

sudo sshd -t

No output means the file is valid. Then apply the change:

sudo systemctl reload ssh

On some systems the service is called sshd instead of ssh. A reload keeps existing sessions alive, which is what you want.

Test from a new window

Without closing your original session:

  1. Open a new terminal and log in as your normal user, with your key. It should work.
  2. Try to log in as root. It should be refused.
  3. If you can, try with a password, from a different computer that does not have the key. It should be refused.

Only close the original session when all three behave correctly.

Changing the port

Many guides suggest moving SSH from port 22 to another number. This cuts the noise in your logs, because bots mostly scan the default port, but it is not real security, because a scan finds the new port quickly. If you do it:

  • Open the new port in your firewall before changing anything. See Set up a firewall on your VPS with UFW.
  • On Ubuntu 24.04 and newer, SSH may be started by a socket, which means the Port line in the config may be ignored, and the port is set in the socket's settings instead. If the port does not change, check systemctl status ssh.socket, and follow the distribution's notes for changing it.
  • Remember to connect with -p NEWPORT afterwards.

If this sounds fiddly, leave the port alone and rely on keys and a tool that blocks repeated failures, as in How to install Fail2ban on Ubuntu.

Common mistakes

MistakeResult
Disabling passwords before testing keysYou are locked out
Editing the main file but a drop-in overrides itYour change does nothing
Forgetting AllowUsers for a second adminThey cannot log in
Closing the only session after a changeNo way to fix an error
Changing the port without opening the firewallYou are locked out

If you do lock yourself out, use the console in your provider's dashboard, which does not depend on SSH, and revert the change.

Keep it that way

Configuration drifts. After a major upgrade, or if you change anything, run sudo sshd -T to print the settings the server is really using, and compare them with what you intended. Keep your system updated, as explained in Turn on automatic security updates, and read Basic security for a new VPS for the rest of the checklist.

Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.