Initial Server Setup & Hardening

When you rent a fresh virtual server (a computer you rent in the cloud, also called a VPS — Virtual Private Server) it usually arrives wide open: only the root account exists, login is by password, and there is no firewall. That is dangerous, because automated bots scan the whole internet and try to log in to brand-new servers within minutes. This page is the canonical checklist you run on every new Ubuntu box, in order, before you install anything else. Do these steps once and your server is safe enough to actually build on.

This is the runbook (a fixed, repeatable list of steps you follow every time) that ties together user management, networking, and security. We target Ubuntu 22.04 LTS and 24.04 LTS — the two long-term-support releases you will see most in 2026. “LTS” (Long-Term Support) means Ubuntu ships security updates for it for five years, so it is the only kind you should run on a server.

Step 1 — Log in and update everything

Your cloud provider gives you the server’s public IP address and a way to log in as root. Connect over SSH (Secure Shell — the encrypted protocol you use to control a remote server from your terminal):

ssh [email protected]

The very first thing to do is update the package lists and upgrade installed software, so you start from the latest security patches. apt is Ubuntu’s package manager (the tool that installs and updates software).

apt update && apt upgrade -y

Output:

Get:1 http://archive.ubuntu.com/ubuntu noble InRelease [256 kB]
...
Reading package lists... Done
Building dependency tree... Done
42 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

If the upgrade installs a new kernel (the core of the operating system), reboot at the end with reboot.

Step 2 — Create a non-root sudo user

root is the all-powerful account. You should never use it for daily work, because one typo can destroy the system and every bot on earth tries to break into it. Instead, create a normal user and give it sudo rights. sudo (Super User DO) lets a normal user run admin commands by typing their own password first.

adduser deploy

This prompts for a password and a few optional details. Then add the user to the sudo group:

usermod -aG sudo deploy

-aG means “add to group” (the a is important — without it you would remove the user from all other groups). Test it by switching to the new user and running an admin command:

su - deploy
sudo whoami

Output:

[sudo] password for deploy:
root

Seeing root confirms the new user can act as an admin.

Step 3 — Set up SSH key authentication

A password can be guessed or brute-forced. An SSH key is a pair of cryptographic files — a private key you keep on your laptop and a public key you put on the server — that together are practically impossible to guess. Generate the key on your own computer, not on the server:

ssh-keygen -t ed25519 -C "[email protected]"

ed25519 is the modern, fast, secure key type — prefer it over the older rsa. Then copy the public key to the server (still from your laptop):

ssh-copy-id [email protected]

Now confirm you can log in as deploy with the key, in a new terminal, before changing anything else:

ssh [email protected]

Keep your existing root session open until you have confirmed key login works in a separate window. If you lock yourself out before testing, you can be permanently shut out of your own server.

Step 4 — Harden the SSH server

Now lock SSH down. Edit the SSH server config:

sudo nano /etc/ssh/sshd_config

Set these three lines (uncomment them and change the values):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Setting	What it does	Why
PermitRootLogin no	Blocks direct root login	Forces use of the sudo user; removes the #1 bot target
PasswordAuthentication no	Disables password login	Stops all brute-force attacks; keys only
PubkeyAuthentication yes	Allows key login	This is now your only way in

Apply the change by restarting the SSH service. systemctl is the command that controls services (background programs) managed by systemd, Ubuntu’s service manager.

sudo systemctl restart ssh

On Ubuntu 24.04 the service may be socket-activated; if restart ssh does nothing, run sudo systemctl restart ssh.socket. Always test login in a new terminal after restarting.

Step 5 — Enable the firewall (ufw)

A firewall blocks all network traffic except what you explicitly allow. Ubuntu ships ufw (Uncomplicated Firewall), a simple front-end for this. Allow SSH first — if you enable the firewall without it, you will be locked out.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

Output:

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

Later, when you run a web server, open ports 80 (HTTP) and 443 (HTTPS) with sudo ufw allow 'Nginx Full'. Open only the ports you actually need.

Step 6 — Set the timezone

Logs and scheduled jobs use the server clock, so set a sensible timezone (UTC is the safe default for servers):

sudo timedatectl set-timezone UTC
timedatectl

Output:

               Local time: Mon 2026-06-15 14:02:11 UTC
           Time zone: UTC (UTC, +0000)
 System clock synchronized: yes

Step 7 — Optional but recommended hardening

Install fail2ban, a tool that watches login attempts and automatically bans IP addresses that repeatedly fail. Also enable automatic security updates so patches install themselves.

sudo apt install fail2ban unattended-upgrades -y
sudo systemctl enable --now fail2ban
sudo dpkg-reconfigure --priority=low unattended-upgrades

enable --now both starts the service immediately and makes it start on every boot.

Best Practices

• Always create and use a non-root sudo user; reserve root for emergencies only.
• Use SSH keys and disable password login entirely — this single change stops nearly all attacks.
• Never enable ufw before allowing SSH, and never restart sshd without an open backup session.
• Keep unattended-upgrades on so security patches land without you remembering.
• Prefer ed25519 keys over rsa, and a fresh key per laptop rather than reusing one everywhere.
• Run apt update && apt upgrade on a schedule, and reboot after kernel updates.
• Snapshot the server image once setup is done, so you can rebuild a hardened box in seconds.

Related Topics

• Renting a VPS
• Cloud providers
• What is cloud computing
• Virtual machines
• IaaS, PaaS & SaaS