SSH Hardening Checklist: How to Secure a Linux VPS

1. Update the system and turn on automatic security updates

Install pending updates first: apt update refreshes the package lists and apt upgrade installs the upgrades. [1]

sudo apt update
sudo apt upgrade

On Ubuntu, security updates install automatically through the unattended-upgrades package, which is installed by default and runs once a day. Both values in /etc/apt/apt.conf.d/20auto-upgrades should be "1", and a dry run shows what it would install. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

It does not reboot on its own, because Unattended-Upgrade::Automatic-Reboot is false by default, so reboot by hand when an update needs it. [1] On Debian 12, if the package or the file is missing, install unattended-upgrades and create the file with the two lines above.

2. Create a non-root sudo user

Do admin work as a named user with sudo, which asks for that user's own password, not root's. Members of the sudo group get full root access through it. [2]

sudo adduser deploy
sudo adduser deploy sudo

adduser asks for a password and a few optional details. [2] Make the password long: SSH will use keys, but sudo still asks for it. Then check the account; sudo whoami should print root.

su - deploy
sudo whoami

On Debian 12, if the sudo command is missing, install it as root with apt install sudo first.

3. Generate an ed25519 key on your computer

Create the key pair on your own computer, not on the server. Ubuntu recommends the ed25519 type for its shorter keys and lower computing cost, and ssh-keygen asks for a passphrase that protects the private key. [3]

ssh-keygen -t ed25519

Keep the default file name. The private key is ~/.ssh/id_ed25519; the public key you copy to servers is ~/.ssh/id_ed25519.pub. [3]

On Windows, run the same command in PowerShell; it saves the pair in the .ssh folder of your user profile. Microsoft advises against an empty passphrase and warns that anyone who gets the private key can sign in as you. [4]

ssh-keygen -t ed25519

4. Copy the public key to the server

On Linux and macOS, ssh-copy-id appends your public key to ~/.ssh/authorized_keys for the user on the server. [3]

ssh-copy-id deploy@203.0.113.10

Microsoft's guide copies keys with PowerShell or scp instead. [4] For a Linux server, this line appends your key and makes the folder and the file writable by you only:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

sshd checks these permissions before it accepts a login, through StrictModes, which is on by default. [5] Then run ssh deploy@203.0.113.10 in a new terminal: you should get in without the account password. If not, follow the server's SSH log while you retry: [3]

sudo journalctl -fu ssh.service

5. Write your settings in a drop-in file

On Ubuntu, /etc/ssh/sshd_config starts with Include /etc/ssh/sshd_config.d/*.conf, and OpenSSH keeps the first value it reads for most settings, so files in that folder override the main file. [3] Included files are read in lexical order and, for each keyword, the first value sshd obtains wins, [5] so name yours 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

From the sshd_config manual:

• PermitRootLogin no stops root from logging in over SSH. The default, prohibit-password, refuses passwords for root but still accepts keys. [5]
• PasswordAuthentication no turns off password logins, which are allowed by default. [5]
• KbdInteractiveAuthentication no turns off keyboard-interactive logins, a separate method that is also on by default; its old name is ChallengeResponseAuthentication. [5]
• AllowUsers deploy (optional) lets only the listed users log in. Unlike most keywords, each AllowUsers line adds to the list. [5] Spell the name exactly, or nobody gets in.

Treat the sudo account like root from now on: Ubuntu's openssh notes call any account you can escalate to root from equivalent to root against outside attacks. [6] On Debian 12, first confirm the Include line with grep -n Include /etc/ssh/sshd_config.

6. Check for files that turn passwords back on

Since the first value wins, any file that sorts before yours beats it. Search the folder:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

On cloud images, cloud-init writes the SSH settings it manages to /etc/ssh/sshd_config.d/50-cloud-init.conf whenever sshd_config includes that folder. [7] If that file says PasswordAuthentication yes, it beats every file that sorts after it, which is why yours starts with 00. Change it to no too, so the files agree.

7. Test the config and restart SSH

Test the files before you restart: a bad setting can stop sshd from starting, and SSH may be your only way in. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Fix anything sshd -t reports first. After the restart, keep your session open and test from a second terminal:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

The first login should work and the second should be refused. If your login fails, undo the change in the open session and check the SSH log from step 4. [3]

8. Change the port on Ubuntu 24.04 (optional)

On Ubuntu 24.04, ssh.socket listens on port 22 through systemd socket activation. A generator turns the Port lines in sshd_config and its drop-in files into socket settings, so after a port change you reload systemd and restart ssh.socket. [6]

sshd accepts more than one Port line, [5] so keep 22 while you test the new port:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Test the new port from a second terminal. Then delete Port 22, repeat the three commands and use port 2222 in steps 9 and 10.

ssh -p 2222 deploy@203.0.113.10

On Debian 12, check first whether the socket is in use. If it is inactive, restarting the service applies the change.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Allow SSH in UFW, then enable it

UFW is installed disabled and, once enabled, denies incoming traffic by default. Its manual warns that ufw enable may drop SSH connections, so add the SSH rule first. [8]

Use limit for SSH rather than allow. A limit rule still allows connections but denies an address that tries to open 6 or more within 30 seconds. Do not add both rules, because UFW uses the first rule that matches. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

UFW asks for confirmation when you enable it over SSH. [8] If you moved SSH, limit 2222/tcp instead. On Debian 12, install UFW first if the command is missing. To take SSH off the public internet altogether, reach it only through a WireGuard private network. For protection further out, see our DDoS protection checklist for VPS hosting.

10. Add Fail2ban for the sshd jail

On Ubuntu 24.04, the package ships /etc/fail2ban/jail.d/defaults-debian.conf, which enables the sshd jail, sets backend = systemd and bans through nftables. [9] The systemd backend reads the systemd journal, so the jail needs no separate log file. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

Fail2ban's own jail.conf bans an address for 10 minutes once it fails 5 times within 10 minutes, and tells you not to edit that file: put your changes in jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Replace 198.51.100.7 with your own fixed address, or delete it. The stock jail uses port = ssh, so add port = 2222 if you moved SSH. [10] On Debian 12, keep backend = systemd here and install python3-systemd, the systemd Python library this backend uses. [10] Then restart Fail2ban and check that it runs:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Check what else is listening

Every open port is another way in. UFW's listening report shows each listening TCP port and open UDP port, its address (* means every interface), the program behind it and the rules that apply. [8]

sudo ufw show listening

A service bound to 127.0.0.1 is reachable only from the server. Switch off public ones you do not need with systemctl disable --now, as Ubuntu's openssh notes do for ssh.socket. [6]

sudo systemctl disable --now SERVICE_NAME