Securing a newly created Ubuntu 24.04 server: first 10 things to do

A newly created Ubuntu 24.04 VPS comes with a configuration designed for convenience, not security. Root enabled, no firewall active, no SSH keys configured. Before deploying any service on it, run through this checklist. Commands tested on Ubuntu 24.04 LTS (noble), to be executed in order because some steps, if reversed, will lock you out of the server.

1. Connect and immediately create an unprivileged user

adduser deploy
usermod -aG sudo deploy

From now on, work with deploy, not root. Test immediately with sudo whoami from that user before closing the root session: it should return root.

2. Copy your public key to the new user

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Or, locally: ssh-copy-id deploy@SERVER_IP. Verify that key-based login works before touching password authentication.

3. Disable root login via SSH

On Ubuntu 24.04, the default value of PermitRootLogin in /etc/ssh/sshd_config is already prohibit-password, so root login with a password is blocked from installation. To disable it entirely, even via key:

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no
PasswordAuthentication no

Watch out for a detail that confuses many: if a file in the /etc/ssh/sshd_config.d/ directory sets PermitRootLogin again, that value overrides the main file, because it gets included after. Check with:

grep -rn "PermitRootLogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Before restarting, verify the syntax and then apply:

sudo sshd -t
sudo systemctl restart ssh

Keep the current session open and open a second one to test login: if something goes wrong, the first session still lets you fix it.

4. Change the SSH port (optional, reduces log noise)

In the same file:

Port 2222

It's not real security, but it reduces the number of automated brute-force attempts on port 22. If you change it, remember to open it on ufw in the next step, otherwise you'll be locked out.

5. Enable ufw with only essential ports

First rule: open the SSH port before enabling the firewall, otherwise you'll lock yourself out.

sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If you haven't changed the SSH port, use sudo ufw allow 22/tcp or, more readable, sudo ufw allow OpenSSH. Every extra port opened is a port you need to justify: if the server only acts as a backend behind a reverse proxy, ports 80 and 443 might not even be needed.

6. Verify that unattended-upgrades is truly active

On Ubuntu Server 24.04, the unattended-upgrades package is pre-installed and automatic installation of security updates is already enabled after system installation. It's not a setting to activate from scratch: it's one to verify.

cat /etc/apt/apt.conf.d/20auto-upgrades

The expected content is:

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

If the file is missing or empty, install the package and reconfigure:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

By default, the mechanism applies only updates from the -security repository, leaving out regular updates (-updates): the policy is defined in /etc/apt/apt.conf.d/50unattended-upgrades, in the Unattended-Upgrade::Allowed-Origins block. If you want to include non-security updates too, uncomment the line "${distro_id}:${distro_codename}-updates"; in that file: it's a choice that exposes you to more uncontrolled changes, so on a production server most sysadmins leave it disabled.

Logs from every execution end up in /var/log/unattended-upgrades/, useful to check if an overnight reboot catches you by surprise.

7. Block direct root login on the system too

Beyond SSH, it's worth blocking root locally/on the console if you don't need it:

sudo passwd -l root

The command locks the password, it doesn't delete the account: sudo -i from a privileged user still works.

8. Set a sensible timezone and hostname

Not security per se, but consistent timestamps in logs help when you need to correlate an event:

sudo timedatectl set-timezone Europe/Rome
sudo hostnamectl set-hostname server-name

9. Separate the deploy user from application service users

The deploy user created in step 1 is for logging in, doing sudo, managing the system. It shouldn't be the same account running your web application or database. For each service, create a dedicated system user with no shell:

sudo adduser --system --no-create-home --group appname

That way, if an application gets compromised, the attacker inherits appname permissions, not a user with sudo.

10. Final verification before proceeding

Before installing any other software, run this sequence of checks:

sudo sshd -T | grep -i permitrootlogin
sudo ufw status verbose
systemctl status unattended-upgrades
sudo passwd -S root
awk -F: '($3 == "0") {print}' /etc/passwd

The last command should return only the root line: if a second user with UID 0 appears, there's a serious problem to fix before anything else.

From here on, the server is ready for the next steps: fail2ban or crowdsec for brute-force protection, automated backups, monitoring. But that's another article.