How to Harden SSH for VPS Without Lockout

SSH na the first thing you suppose harden

SSH na how you dey control your server, so na the lock wey every attacker go first try. Once VPS enter online, scanners go start guess usernames and passwords for port 22. You fit watch am happen for your logs within minutes. To harden SSH mean say you remove the things wey dem fit guess: turn off password login completely, turn off root login, and allow only cryptographic keys. Once you do this, the constant guessing no fit succeed again, because password no dey to find.

This assume say SSH don already dey work. If you fit log in, you fit harden am. Do the steps in order, and keep your current session open until new one work, so mistake no go lock you out.

Step 1: First make sure key authentication dey work

Key authentication dey replace password with key pair: private key wey dey stay for your computer and public key wey you put for server. The server dey prove say you hold the private key without the key ever comot from your machine. Before you disable passwords, confirm say keys dey work, otherwise you fit lock yourself outside.

For your own computer, create key if you never get one:

ssh-keygen -t ed25519

Copy the public half go the server:

ssh-copy-id user@your-server

Then open new SSH session. If e let you enter without asking for password, your key dey work and you fit safely turn passwords off. If e stop you with Permission denied (publickey), that one error dey hide five different faults, and the ssh -v output go tell you which one you get before you change anything else. If keys still new to you, or you dey use more than one computer, SSH key management basics dey explain the complete model: one key for each device, the permissions sshd dey require, and how to revoke key when laptop go missing.

Step 2: Drop-in file na make sshd more secure

No edit /etc/ssh/sshd_config directly. Ubuntu 24.04 dey read drop-in files from /etc/ssh/sshd_config.d/. Small file for there dey cleaner, e go survive package upgrades, and e easy to remove if problem happen. The name matter: sshd dey keep the first value wey e read for each setting. Ubuntu cloud images dey ship 50-cloud-init.conf with PasswordAuthentication yes for this directory. Name your file 00- so e go sort before that one and take effect. A 99- file go lose without any warning. Create one:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Put this inside:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Each line dey close one way enter. PasswordAuthentication no na the main one: when passwords off, brute-force attack no get password to try. KbdInteractiveAuthentication no dey close another password-style path. PermitRootLogin no mean say attacker must know your username and get your key. E no fit target only the one account, root, wey dey exist for every box.

Step 3: Test config, den reload am

Check config for mistakes before you apply am, so typo no go spoil the service:

sudo sshd -t

If e no print anything, config dey valid. Reload SSH:

sudo systemctl reload ssh

Then check the settings wey sshd dey actually use, so you fit catch drop-in wey another file don override:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Both suppose show no. Now, without closing your current session, open brand-new one from another terminal. If e log you in with your key, you don finish. If anything no correct, your first session still dey open so you fit fix am. This overlap na the safety net, so never skip am.

Step 4: The optional non-standard port

To move SSH from port 22 go something like 2222 no really make am more secure, because attacker wey serious go scan all ports. Wetin e do na to reduce log noise, because most automated scanners only try 22. If you want am, add Port 2222 to your drop-in file, allow the new port for firewall first, then run sudo systemctl daemon-reload && sudo systemctl restart ssh.socket and connect with ssh -p 2222. For Ubuntu 24.04, ssh.socket dey control the listening port, so plain reload ssh go leave sshd for 22; na restarting the socket go make e use the new port. See am as tidiness, no be protection.

Step 5: Add the other defences

Hardened SSH keys na the foundation, and two more layers dey on top of dem.

Fail2ban dey monitor your logs and ban addresses wey keep failing. This one reduce scanner noise and remove dem early. E work well with key-only auth: see Fail2ban for Ubuntu to stop SSH attacks.

Stronger one na to keep SSH completely away from public internet. If you put SSH behind WireGuard VPN and firewall port 22 to the tunnel, nobody outside the VPN fit even reach am. Brute-force guessing go stop being possible, instead of just becoming difficult. All this assume say default-deny firewall dey underneath, wey be UFW setup for the VPS.

SSH na only one item for a bigger checklist: the first 10 minutes for a new VPS arrange the steps in order, while automatic security updates for Ubuntu keep the box patched afterwards. Locking the door no protect the services behind am. So if this same VPS dey run a password vault, a hardening pass for Vaultwarden cover the two things key auth no ever touch: the admin token and the backup file.

FAQ

How I fit disable password login for SSH on Ubuntu 24.04?

Create drop-in file for /etc/ssh/sshd_config.d/00-hardening.conf (the 00 prefix make e sort before 50-cloud-init.conf, wey PasswordAuthentication yes for am for otherwise win, because sshd dey keep the first value wey e read) wey contain PasswordAuthentication no and KbdInteractiveAuthentication no. Run sudo sshd -t to check am, then sudo systemctl reload ssh. Confirm say key login dey work for new session before you depend on am. If you edit drop-in instead of sshd_config, package upgrades no go overwrite am, and e easy to undo.

I suppose disable root login over SSH?

Yes. Set PermitRootLogin no so nobody fit log in directly as root. Log in with your normal user and use sudo for admin tasks. Root dey exist for every Linux box, so if you leave am reachable, attacker get known username to target. If you disable am, dem must know your account name and get your key.

Changing SSH port go make my server more secure?

No, no be in any meaningful way. If you move comot from port 22, lazy scanners wey only probe 22 no go see you easily. This reduce log noise, but real attacker go scan every port and still find am. Na key-only authentication really dey stop break-ins. If you change the port, open the new one for firewall first, then run sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; for Ubuntu 24.04, socket own the listener, and plain reload go leave sshd for port 22.

I need Fail2ban if I dey use SSH keys?

E optional, but e still useful. With key-only authentication, password guessing no fit succeed, so Fail2ban no be wetin dey keep attackers out. E dey rate-limit repeated failures from one address. This reduce scanner noise for your logs and remove repeat offenders early. But slow attack wey dey come from many addresses fit remain below the ban threshold. Run am together with key auth, and if possible keep SSH behind VPN.

How I fit recover if I lock myself out of SSH?

Use your provider web console. E fit reach the server through serial or VNC connection wey no dey pass through SSH. From there, you fit log in, fix the sshd drop-in file, and reload the service. Na exactly why you suppose test new SSH config for second terminal before you close the first session. Na also why key authentication suppose already dey work before you turn passwords off.