SKIP TO CONTENT
FL1GHT5 Network

Apr 05, 2024 · Privacy & Self-Hosting / Beginner · ~3 MIN READ

SSH Hardening Checklist for Ubuntu Servers

Safely reduce SSH exposure without locking yourself out — keys, root login, port changes, UFW, and Fail2ban.

Who This Is For

Beginner. A practical reference you’ll come back to on every new server.

Think of it like changing the locks and adding a peephole after buying a house. The door still opens the same way for you, but now only people with the right key get in, and you can actually see who’s knocking.

What You’ll Build

Key-only SSH access from your local network or VPN, with root password login disabled, done in an order that never locks you out.

Prerequisites

  • An Ubuntu Server with an active SSH session open
  • Console or KVM access as a fallback in case something goes wrong
  • A local SSH key pair (or willingness to generate one)

Before Changing Anything

  • Keep one active SSH session open at all times while making changes
  • Confirm you have console/KVM access as a fallback
  • Back up /etc/ssh/sshd_config before editing it

Create a Non-Root Admin User

$ adduser youruser
$ usermod -aG sudo youruser

Install Your SSH Key

$ ssh-copy-id youruser@server-ip

Test logging in with the key from a second terminal before closing your original session.

Disable Password Authentication

Only after confirming key login works. Edit /etc/ssh/sshd_config:

$ PasswordAuthentication no
$ PermitRootLogin no
$ sudo systemctl restart sshd

Restrict Allowed Users

Optionally add AllowUsers youruser to sshd_config to explicitly whitelist who may connect at all.

Configure the Firewall

$ sudo ufw allow OpenSSH
$ sudo ufw enable

Audit the Result

$ sudo sshd -t
$ ss -tulpn | grep ssh

Check /var/log/auth.log periodically for repeated failed login attempts.

Security & Backup Notes

  • Changing the default SSH port reduces automated scanning noise but is not a real security control on its own
  • Pair this with Fail2ban or CrowdSec for automated ban enforcement (see those articles)
  • Restrict SSH to trusted subnets or a VPN if the server is ever reachable from the internet

Troubleshooting

  • Public key rejected, check ownership and permissions: ~/.ssh must be 700, authorized_keys must be 600
  • Locked out after disabling password auth, use console/KVM access to re-enable it temporarily and fix the key setup
  • Firewall blocks SSH entirely, always allow SSH explicitly before enabling UFW, not after
  • sshd fails to restart, run sshd -t first; it will point out the exact config syntax error

Lab Finish Line

Key-only SSH from the local network or VPN, with root password login disabled.

What to Build Next

NEXT STEP

Want this running in your business?

Everything in the Lab is a service we deliver. If this guide describes your problem, skip the DIY weekend — send the brief.

FIVE MINUTES TO WRITE · A WRITTEN PLAN BACK · NO SALES CALL UNLESS YOU WANT ONE