You have just received an Ubuntu server: an IP address, a root password and an empty terminal. What you do in the next half hour decides much of what follows. A server set up properly on day one runs for months without drama, while one left as delivered is eventually either compromised or simply runs out of room and slows down.
This article walks through the first ten steps in order. We assume Ubuntu 24.04 LTS, though most commands work on other releases too. The security steps are deliberately brief because how to secure a Linux server covers them in depth. If connecting is new to you, read what SSH is and how to connect first.
Step 1: Connect and update the system
Connect over SSH and update packages before doing anything else. Running apt update and then apt upgrade does it. If the kernel or a core library changed, restart once. Images are sometimes built weeks or months before you receive them, so this step pulls in security fixes straight away.
Step 2: Create a new user with sudo
Daily work as root is risky, since one typo can damage the whole system. Create a user with adduser, give it a strong password, and add it to the sudo group with usermod. Log in as that user and check that sudo works. From now on you do all administration with this account.
Step 3: Use SSH keys instead of passwords
Passwords can be guessed, keys effectively cannot. On your own computer create a key pair with ssh-keygen and copy the public key to the new user with ssh-copy-id. Once you have confirmed that key login works, set PasswordAuthentication to no in sshd_config and set PermitRootLogin to no. Restart the ssh service afterwards. Keep a second session open while you do this so a mistake does not lock you out.
Step 4: Turn on the firewall with ufw
ufw ships with Ubuntu and only needs enabling. Allow ssh first, or you will lock yourself out immediately. Then open only the ports you really need, such as 80 and 443 for a website. Finally run ufw enable. The rule is simple: everything closed, only what is needed open.
Step 5: Set the timezone and clock
Logs, cron jobs and billing all rely on the server clock. Set the timezone with timedatectl. If your services run across several servers, keeping them all on UTC is the easiest way to avoid confusion. Time sync through systemd-timesyncd is on by default; check with timedatectl status that NTP is active.
Step 6: Add swap
Many cloud servers ship without swap. On a small-RAM machine, when memory runs out the kernel kills processes and your service can drop suddenly. Create a swap file sized to your RAM (equal to or half of RAM is common on small servers), enable it with mkswap and swapon, and add it to fstab so it survives a reboot. Lower swappiness to around 10 so swap is used only when needed. Swap is a cushion, not a replacement for RAM.
Step 7: Install fail2ban
Any server with port 22 open starts receiving failed login attempts within minutes. fail2ban reads the logs and temporarily blocks addresses that fail repeatedly. Install it with apt, create a jail.local that enables sshd, and start the service. Once you use keys it matters less, but it keeps the logs clean and the load down.
Step 8: Automatic security updates
You should not have to log in daily to patch. Install unattended-upgrades and enable it with dpkg-reconfigure so security updates install on their own. If you want the server to reboot itself when needed, set automatic reboot in the configuration file at a fixed quiet time. On sensitive servers, leave that off and decide yourself.
Step 9: Snapshots and backups
No setting replaces a backup. Before installing anything, take a snapshot of the clean state, so that if something breaks later you can go back in seconds. Snapshots are great for quick restore points, but for data you care about, also keep a separate backup off the server: database dumps, application files and configuration. rsync, restic or borg can schedule that. A backup you have never tried to restore is not yet a backup.
Step 10: Simple monitoring
You do not need a heavy monitoring stack on day one, but you do need to know the server is alive. At a minimum:
- Learn htop, df and free for a quick look at CPU, disk and memory.
- Use an external service that checks your site or port every few minutes and tells you when it fails.
- Read service logs with journalctl and keep an eye on how much disk the logs use.
- For traffic, bandwidth vs traffic explains what to count.
What comes next
Your server is now tidy, safer and ready. Depending on the project, the next step may be installing Docker, which we cover in Docker on a VPS, then a web server or a bot. If you are still choosing what to run, choosing a VPS for a website, bot or VPN helps. And for the basics of what a VPS is, see what is a VPS.
FAQ
What is the first thing to do on a new Ubuntu server?
Update the packages, then create a non-root user with sudo. Everything else, such as SSH keys and the firewall, builds on those two.
Should I disable root login over SSH?
Yes, we recommend it. The root name is the same everywhere, so attacks focus on it. With a sudo user and an SSH key there is no reason to log in as root directly.
Do I need swap?
If RAM is small or your memory use spikes, yes. Swap stops the system from killing programs at the moment memory runs out. It is not a substitute for RAM, though, and if it is used constantly you should upgrade the plan.
Do I still need fail2ban if I use SSH keys?
Not strictly, since password login is off and guesses go nowhere. But fail2ban keeps logs clean and reduces load, so it is a cheap extra layer.
What is the difference between a snapshot and a backup?
A snapshot is an image of the whole server at one moment, ideal for quick rollback. A backup keeps your files and data separately from the server and saves you if the server itself is lost. Ideally you have both.
Do these steps work on other Ubuntu versions?
Mostly yes, because tools like ufw and apt are the same across LTS releases. Only small details such as service names or file paths may differ.
Ubuntu servers on CloudSnap
On CloudSnap, Ubuntu and other Linux images are available in every location, with root access and management from the Telegram bot or the web panel. Hourly billing on most foreign servers lets you practise these ten steps on a throwaway server and delete it afterwards, and snapshots, a console and 24/7 support in Telegram are there when you need them. Start from the Linux cloud server page.