how to secure SSH for VPS

Why SSH na first thing wey you must harden

SSH na how you take control your server, so na him be the lock wey every attacker dey try first. As soon VPS go online, scanners go start to guess username and password for port 22. You fit see am dey happen for your logs within minutes. Hardening SSH na to remove all the things wey dem fit guess: turn off password login completely, turn off root login, and make only cryptographic keys work. Once you do am, all those constant guessing no go fit work again, because no password dey for dem to find.

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

Step 1: Make sure key authentication work first

Key authentication dey replace password with key pair: private key wey go stay for your computer and public key wey you go put for server. Server go confirm say you get the private key without the key ever leave your machine. Before you disable passwords, make sure keys dey work, or you go lock yourself out.

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

ssh-keygen -t ed25519

Copy the public half to the server:

ssh-copy-id user@your-server

Then open new SSH session. If e let you enter without ask for password, your key dey work and you fit turn passwords off safely. If you be new to keys, or you dey use more than one computer, SSH key management basics go explain the full model: one key for every device, the permissions wey sshd need, and how to revoke one key if laptop lost.

Step 2: Harden sshd with a drop-in file

No edit /etc/ssh/sshd_config directly. Ubuntu 24.04 dey read drop-in files from /etc/ssh/sshd_config.d/. Small file for inside there dey cleaner, e go still dey even when you upgrade package, and e easy to remove if wahala start. Name dey matter: sshd go keep the first value wey e read for every setting, and 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 win; 99- file go lose silently. 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

Every line dey close one door. PasswordAuthentication no na the big one: if you turn passwords off, brute-force attack no go get anything to brute-force. KbdInteractiveAuthentication no dey shut another password-style path. PermitRootLogin no mean say attacker must know your username and hold your key, e no go fit just target the one account, root, wey dey every box.

Step 3: Test the config, then reload

Check the config for mistake before you apply am. This way, typo no go break the service:

sudo sshd -t

If nothing print for screen, the config valid. Reload SSH:

sudo systemctl reload ssh

Then check the settings wey sshd dey use. This one go help you catch any setting wey another file don take over:

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

Both must show no. Now, no close your current session. Open brand new session from another terminal. If e log you in with your key, you don finish. If something wrong, your first session still open so you fit fix am. This overlap na your safety net, so no skip am.

Step 4: The optional non-standard port

To move SSH from port 22 to something like 2222 no dey make am more secure for real, because any attacker wey serious go scan all ports. Wetin e dey do na to reduce log noise, because most automated scanners only dey try port 22. If you want do am, add Port 2222 to your drop-in file, first allow the new port for firewall, 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 if you just do plain reload ssh, sshd go still dey on 22; na to restart the socket dey make am pick the new port. Treat am as way to arrange things, no be protection.

Step 5: Add more layers of defence

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

Fail2ban dey watch your logs and e dey ban any address wey dey fail repeatedly. Dis one dey reduce scanner noise and e dey kick dem out early. E dey work well with key-only auth: see how to use Fail2ban on Ubuntu to stop SSH attacks.

Even better na to keep SSH off the public internet entirely. If you put SSH behind a WireGuard VPN and you firewall port 22 to only the tunnel, nobody wey no dey the VPN no go fit reach am. Brute-force guessing go stop to be possible, e no go just be difficult again. All of dis depend on default-deny firewall wey dey ground, like how to set up UFW on the VPS.

SSH na just one part of big checklist: the first 10 minutes on a new VPS go show you the steps for correct order, and how to do automatic security updates on Ubuntu go keep the box patched after dat.

FAQ

How I go take disable password login for SSH for Ubuntu 24.04?

Create one drop-in file for /etc/ssh/sshd_config.d/00-hardening.conf (00 prefix dey make am come before 50-cloud-init.conf, because if you no do am, PasswordAuthentication yes go win, since sshd dey take first value wey e read) wey get PasswordAuthentication no and KbdInteractiveAuthentication no inside. Run sudo sshd -t to check am, then run sudo systemctl reload ssh. Make sure say key login dey work for new session before you rely on am. If you edit drop-in instead of sshd_config, e go survive package upgrades and e easy to undo.

I suppose disable root login for SSH?

Yes. Set PermitRootLogin no so nobody go 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 open, attacker go get one username wey dem already know to target. If you disable am, dem must know your account name and hold your key.

If I change SSH port, my server go more secure?

No, e no go change much. Moving from port 22 dey hide you from lazy scanners wey only dey probe port 22, which dey reduce log noise, but real attacker dey scan every port and dem go find am anyway. Key-only authentication na wetin dey actually 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 dey control the listener, so if you just do plain reload, sshd go still dey port 22.

I need Fail2ban if I dey use SSH keys?

E no mandatory but e still useful. With key-only authentication, person no fit guess password, so Fail2ban no be wetin dey stop attackers. E dey limit how many times person fit fail from one address, which dey reduce scanner noise for your logs and dey kick out repeat offenders early; slow, distributed attack go still pass their ban threshold anyway. Run am alongside key auth, and if you fit, keep SSH behind a VPN.

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

Use your provider web console, wey dey 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 why you suppose test new SSH config for second terminal before you close your first session, and na why key authentication suppose dey work before you turn passwords off.