How to Secure an Ubuntu Server: Lock It Down from Hackers (24.04)

A new server gets its first login attempts within minutes of going online. Bots try common user names and passwords on SSH all day, every day. The good news: almost every break-in into a small Ubuntu server comes through the same few doors, a password login on SSH, missing updates, or an exposed admin panel, and all of them can be closed in ten minutes.

This guide gives you those steps in one tested script for Ubuntu 24.04, explains a trap in cloud images that leaves password login on even after you turn it off, shows how to check the result, and answers the common questions about Ubuntu's safety and support dates.

How safe is Ubuntu from hackers?

Very safe, when it is kept up to date and set up properly. Ubuntu ships with AppArmor protection switched on, gets security updates quickly, and most attacks on Ubuntu servers do not use a flaw in Ubuntu at all: they guess a weak SSH password, use an old version of an app or control panel that was never updated, or log in with a leaked key. Close those, and you have stopped what bots actually try.

Is Ubuntu still good in 2026, and is my version end of life?

Yes. Ubuntu LTS is one of the most used server systems, and Ubuntu 26.04 LTS came out in April 2026. Each LTS gets five years of standard security updates, and five more with Expanded Security Maintenance (ESM) through Ubuntu Pro, which is free for personal use on a few machines:

For a new server, choose 24.04 or 26.04. If you still run 20.04, either attach Ubuntu Pro or plan the move now.

Ubuntu server setup: make an SSH key first

Logging in with a key instead of a password is the single most important step. On your own computer:

# On YOUR computer (Windows PowerShell, macOS or Linux), not on the server
ssh-keygen -t ed25519 -C "you@laptop"

# Show the public key, then paste it into your VPS provider's "SSH keys" page
# when you create the server (or into /root/.ssh/authorized_keys on the server)
cat ~/.ssh/id_ed25519.pub

Most providers let you add this public key when you create the server, so it lands in /root/.ssh/authorized_keys. The script below refuses to run without it, because it switches password login off.

Try it: lock down an Ubuntu server with one script

On a fresh Ubuntu 24.04 server, log in as root, save this as secure-server.sh, and run bash secure-server.sh yourname. Keep that SSH window open until you have logged in as the new user from a second window.

#!/bin/bash
# First security steps for a new Ubuntu 24.04 server (22.04 works too).
# Run as root:  bash secure-server.sh yourname
# Keep this SSH window open until you have logged in as the new user from a second window.
set -euo pipefail

NEWUSER=${1:-}
[[ $NEWUSER =~ ^[a-z][a-z0-9_-]{1,30}$ ]] || { echo "Give a user name (small letters):  bash $0 yourname"; exit 1; }
[ "$(id -u)" -eq 0 ] || { echo "Run it as root"; exit 1; }

# The new user must be able to log in with a key before passwords are switched off
KEYS=/root/.ssh/authorized_keys
[ -s "$KEYS" ] || { echo "No SSH key in $KEYS. Add your public key there first, or you will be locked out."; exit 1; }

# 1. Updates
apt-get update
DEBIAN_FRONTEND=noninteractive apt-get -y full-upgrade
DEBIAN_FRONTEND=noninteractive apt-get -y install ufw fail2ban unattended-upgrades

# 2. A normal user with sudo, using the same SSH key as root
id "$NEWUSER" > /dev/null 2>&1 || adduser --disabled-password --gecos "" "$NEWUSER"
usermod -aG sudo "$NEWUSER"
install -d -m 700 -o "$NEWUSER" -g "$NEWUSER" "/home/$NEWUSER/.ssh"
install -m 600 -o "$NEWUSER" -g "$NEWUSER" "$KEYS" "/home/$NEWUSER/.ssh/authorized_keys"
echo "Set a password for $NEWUSER (sudo asks for it):"
passwd "$NEWUSER"

# 3. SSH: keys only, no root login. The file name starts with 00 because sshd keeps the
#    FIRST value it reads, and cloud images ship 50-cloud-init.conf with passwords on.
cat > /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no
EOF
sshd -t                       # stop here if the configuration has an error
systemctl restart ssh

# 4. Firewall: only SSH, web and HTTPS come in
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

# 5. Ban addresses that keep guessing SSH logins
cat > /etc/fail2ban/jail.local <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF
systemctl enable --now fail2ban
systemctl restart fail2ban

# 6. Install security updates automatically
cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

echo "Done. Now, in a NEW terminal, test:  ssh $NEWUSER@YOUR-SERVER-IP"
echo "Close this window only after that login works."

The cloud-init trap: why password login may still be on

Ubuntu's SSH server reads the files in /etc/ssh/sshd_config.d/ in alphabetical order and keeps the first value it finds for each setting. Many cloud images include 50-cloud-init.conf with PasswordAuthentication yes. A file named 99-hardening.conf is read later, so its “no” is ignored and passwords stay on. That is why the script names its file 00-hardening.conf. Always check the setting that is really in force:

# Which SSH settings are really in force? (expect "no" for both)
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'

# Firewall rules, banned addresses, automatic updates
sudo ufw status verbose
sudo fail2ban-client status sshd
systemctl status unattended-upgrades --no-pager

Ubuntu server best practices: how to lock it down

• Keys only for SSH, and a different key per computer, so you can remove one if a laptop is lost
• Install only what you use, and remove test programs when you are done
• Close admin panels to the world: allow ports such as 8083 or 8443 only from your own IP (see free cPanel alternatives)
• Update apps too, not only Ubuntu: panels, WordPress plugins and tools like n8n are where most 2024 to 2026 break-ins started
• Backups somewhere else, tested by restoring one
• Read the logs now and then: sudo journalctl -u ssh --since today shows who tried to log in
• Changing the SSH port cuts down noise in the logs but is not real security. On 24.04, SSH is started by ssh.socket, so after changing Port run sudo systemctl daemon-reload and sudo systemctl restart ssh.socket, and open the new port in ufw first.

What people on Reddit usually recommend

• Keys only, no root login, and automatic security updates cover most of it
• With keys only, fail2ban matters less, but it keeps logs clean and helps with other services
• Use your provider's cloud firewall as a second layer in front of ufw
• Do not trust “security through obscurity” such as odd ports as your only protection

Which Linux OS is most secure?

For servers, the honest answer is: the one you keep updated and understand. Ubuntu LTS, Debian stable, and Red Hat-style systems (RHEL, AlmaLinux, Rocky Linux, with SELinux) are all built and patched for servers. The differences between them matter far less than SSH keys, updates and a firewall. For a personal computer with very high risk, specialised systems such as Qubes OS go further, but that is a different job.

An Ubuntu VPN server with WireGuard

A locked-down Ubuntu server is a good home for your own VPN. Our WireGuard VPS guide has a setup script that works with this firewall: it opens UDP 51820 in ufw by itself and adds each phone with a QR code.

Many servers, many users

One server is fine to secure by hand. Once you run several, or servers that hold customer data, the work changes: the same settings applied by a tool such as Ansible, logs collected in one place, alerts on unusual logins, compliance hardening such as the CIS benchmarks (Ubuntu Pro includes a tool for them), and a plan for who updates what every week.

Apps that run on your own Ubuntu server

Our chat, call and VPN apps run on your own Ubuntu server instead of paid cloud APIs, so a secured VPS is the first step to running them:

• Video dating app and live video chat app: chat and video calls on your own XMPP and TURN servers, set up as in our ejabberd and TURN guide
• VPN app source code: WireGuard and OpenVPN, with a registration script and IP pool for your WireGuard server

Where to go next

• Best VPS for a WireGuard VPN server
• Oracle Cloud free tier VPS
• Free SSL certificate on Ubuntu
• Nginx vs Apache vs LiteSpeed