We earn commissions when you shop through the links below. Learn more
How to Secure SSH on a Linux Server: 10 Hardening Steps
A new server starts getting automated SSH login attempts within minutes of going online. These 10 steps lock SSH down on Ubuntu and Debian without locking you out, with copy-and-paste commands and a single config file you can reuse.
Ubuntu & DebianKey-only loginFail2ban & firewallReady-made config
Before you start
Don’t lock yourself out
- Make sure you can already log in with an SSH key as a non-root user with sudo.
- Keep your current SSH session open while you change settings.
- After each change, test from a second terminal before closing the first one.
- Know where your host’s web console is, in case you need a way back in.
No key yet?
Set up key login first, or step 1 will lock you out. Our guide on how to SSH into a server walks through creating a sudo user and copying your key.
Steps 1–5
Lock down how people log in
Use SSH keys only
Set PasswordAuthentication no and KbdInteractiveAuthentication no. Bots can’t guess a key, so this alone stops almost every brute-force attack.
Turn off root login
Set PermitRootLogin no. Log in as your own user and use sudo, so every admin action is tied to a person.
Allow only specific users
Add AllowUsers deploy (space-separate several names). Any other account is refused, even with a valid key.
Limit login attempts
Set MaxAuthTries 3 and LoginGraceTime 30 so each connection gets only a few quick tries.
Turn off features you don’t use
If you don’t need them, set X11Forwarding no, and consider AllowTcpForwarding no on servers that don’t need tunnels.
Copy and paste
A ready-made SSH hardening config
Instead of editing the main file, put your settings in their own drop-in file, which survives package updates. Create it with sudo nano /etc/ssh/sshd_config.d/00-hardening.conf and paste in:
# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers deploy
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding noChange deploy to your username. SSH uses the first value it reads, and reads these files in alphabetical order, so the 00- prefix makes your settings win over others, such as the 50-cloud-init.conf file many cloud images ship with PasswordAuthentication yes.
Test the config, then apply it
sudo sshd -t && sudo systemctl restart sshConfirm what SSH is really using
sudo sshd -T | grep -Ei "passwordauth|permitroot|allowusers"Steps 6–8
Block attackers at the door
Steps 9–10
Optional extras
9. Change the SSH port (optional)
Moving SSH off port 22 doesn’t stop a determined attacker, but it cuts the noise from bots dramatically. On Ubuntu 24.04 and later, SSH is started by ssh.socket, so set the port there:
sudo systemctl edit ssh.socket
# add in the editor:
[Socket]
ListenStream=
ListenStream=2222Then run sudo ufw allow 2222/tcp, sudo systemctl daemon-reload and sudo systemctl restart ssh.socket, and connect with ssh -p 2222. On older releases, set Port 2222 in your config file and restart ssh instead.
10. Watch your logs
See who has been trying to log in, and spot anything unusual:
sudo journalctl -u ssh --since today
sudo lastb | headFor extra protection on important servers, add two-factor authentication or restrict SSH to your own IP addresses or a VPN.
Need a server?
Need a server to lock down?
Every host below gives you full root access, so you can apply all 10 steps from day one.
Simple cloud servers with great docs. Add your SSH key when you create a Droplet.
From about $4/month
View DigitalOcean deals4 GB of RAM and NVMe storage on the entry VPS plan, with an easy control panel.
About $5.19/month on a 24-month term with our extra 20% off
Get 20% off Hostinger VPSYearly KVM VPS deals for about the price of one month elsewhere. Great for learning.
From about $11/year on promo
View RackNerd dealsPrices are approximate. Compare all VPS hosts, including Vultr and ShockHosting.
FAQ
SSH security questions, answered
What is the most important SSH security setting?
Turning off password logins and using SSH keys only. Almost all SSH attacks are automated password guessing, and key-only login makes that impossible.
Is changing the SSH port worth it?
It is optional. It does not make a server secure on its own, but it greatly reduces automated login attempts and log noise. Key-only login and a firewall matter far more.
Should I disable root login over SSH?
Yes. Log in as a normal user and use sudo instead. If you need root access for automation, PermitRootLogin prohibit-password allows root with keys only.
Is Fail2ban still needed if I use keys only?
It is not strictly required, since bots cannot guess a key, but it still blocks noisy scanners, protects any other services you run and keeps your logs readable.
How do I know if someone is attacking my server?
Check sudo journalctl -u ssh for failed logins and sudo lastb for failed attempts. Seeing many failures from random IP addresses is normal internet background noise; a successful login you do not recognize is not.
What should I do if I lock myself out?
Use the web or recovery console in your hosting provider’s dashboard. It works even when SSH does not, so you can fix the config file and restart SSH.
Use a strong key for your locked-down server
Key-only login starts with a good key. Create an Ed25519 key in seconds, right in your browser.