How to Harden SSH on a VPS

Default SSH is fine for the first login. Before you run production workloads, tighten authentication and exposure.

Baseline checklist

Create a sudo user; install your public key in ~/.ssh/authorized_keys.
Confirm a second SSH session works with that user + key.
Disable password authentication and root password login.
Restrict who can reach port 22 when your IP is stable.
Keep the OS OpenSSH package updated.

sshd_config essentials

Edit /etc/ssh/sshd_config (or a drop-in under /etc/ssh/sshd_config.d/):

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
X11Forwarding no
AllowUsers yoursudoer

Test and reload:

sudo sshd -t && sudo systemctl reload sshd
# Debian/Ubuntu service name may be ssh

Firewall allow list for SSH

sudo ufw allow from YOUR.IP.ADD.RESS to any port 22 proto tcp
sudo ufw delete allow OpenSSH   # only after the allow-list rule works

Fail2ban (optional)

Rate-limit brute force if passwords must remain temporarily enabled. Prefer eliminating password auth instead.

Recovery

If you lock yourself out, use the provider VNC/serial console, fix sshd_config or UFW, and reload. Do not rely on “changing the port” as your only control.

Frequently Asked Questions

Is changing the SSH port enough?

No. Port security through obscurity fails quickly. Prefer keys, disabled password root login, and source restrictions.

Can I break my only login path?

Yes. Always keep a provider web console session open while testing a second SSH session before you disconnect the first.

Need help?

If you are stuck after following this guide, open a ticket from the Chapter22 client area with the exact error, the port or DNS change you made, and whether the service listens locally (ss / Resource Monitor) but fails externally.

Build the server. Grow the community. Start your next chapter.