How to Secure a New Ubuntu VPS: SSH Keys, Firewall and Updates

Why the first ten minutes matter

A fresh VPS gets a public IP address and, within minutes, automated bots start trying to log in over SSH with common usernames and passwords. You can see them in the log of almost any new server. None of this is dangerous if you spend ten minutes on the basics before you install anything else.

This guide walks through the standard first steps on Ubuntu 22.04 or 24.04 (Debian works almost identically): updating the system, creating a normal user, logging in with SSH keys instead of a password, enabling a firewall, switching on automatic security updates and adding Fail2ban. You only need a terminal and the IP address and root password (or key) of your server.

Step 1: Log in and update the system

Connect as root with the IP address from your server panel:

ssh root@YOUR_SERVER_IP

Then refresh the package lists and install all pending updates:

apt update && apt upgrade -y

If the upgrade installs a new kernel, the system will ask you to reboot. Do it now with reboot, wait a minute and log in again.

Step 2: Create a normal user with sudo

Working as root all the time is risky: one wrong command can destroy the system. Create a regular user and give it sudo rights:

adduser deploy
usermod -aG sudo deploy

Pick any username you like instead of deploy, and a long, unique password. You will use it for sudo, not for logging in.

Step 3: Set up SSH key login

An SSH key pair is far stronger than any password. The private key stays on your computer; only the public key is copied to the server.

On your own computer (Linux, macOS or Windows PowerShell) create a key:

ssh-keygen -t ed25519 -C "my-vps"

Accept the default location and set a passphrase. Then copy the public key to the new user:

ssh-copy-id deploy@YOUR_SERVER_IP

On Windows without ssh-copy-id, paste the contents of id_ed25519.pub into /home/deploy/.ssh/authorized_keys on the server.

Now open a second terminal and check that this works:

ssh deploy@YOUR_SERVER_IP
sudo whoami

The second command should print root. Keep the first session open until this succeeds, so you cannot lock yourself out.

Step 4: Disable password and root login

Once key login works, forbid passwords and direct root login. On current Ubuntu the clean way is a drop-in file:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

with this content:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Check the syntax and reload the service:

sudo sshd -t
sudo systemctl reload ssh

Before closing anything, open a third terminal and confirm that ssh deploy@YOUR_SERVER_IP still works. Check with sudo sshd -T | grep -i passwordauthentication that it now says no. Some cloud images ship their own file in that folder that enables passwords; SSH reads files in alphabetical order and the first value wins, which is why the name starts with 00-.

Step 5: Enable the UFW firewall

UFW (Uncomplicated Firewall) is installed on Ubuntu. The rule is simple: deny everything incoming, then allow only what you really use. Allow SSH first, or you will cut your own connection:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Open ports 80 and 443 only if the server will host a website. Every other service (a database, an admin panel, a game server) should get a port only when you need it, ideally limited to your own IP: sudo ufw allow from YOUR_HOME_IP to any port 5432.

Step 6: Turn on automatic security updates

Most break-ins use known bugs for which a patch already exists. Let Ubuntu install security patches by itself:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Answer "Yes". Updates for the kernel still need a reboot now and then; run ls /var/run/reboot-required occasionally, and if the file exists, schedule a restart at a quiet hour.

Step 7: Add Fail2ban against brute force

Fail2ban reads the logs and temporarily blocks IP addresses that fail to log in repeatedly:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

The default settings already protect SSH. With key-only login the bots cannot get in anyway, but Fail2ban keeps your logs clean and saves a little CPU.

A short checklist for every new server

System updated and rebooted.
Non-root user with sudo; root login disabled.
Password login disabled, SSH key with a passphrase.
UFW enabled with only the ports you need.
Automatic security updates on.
Fail2ban running.
Automatic backups or snapshots of anything you cannot lose.

Choosing where to run it

Security is only half of the decision: the location also affects speed. If your visitors are in Europe, a data centre in Germany or elsewhere on the locations page usually gives the lowest latency. HironServer lets you deploy Ubuntu in 50+ countries with hourly, weekly or monthly billing, so you can test a location cheaply; see the pricing page for the current plans.

FAQ

Is it safe to leave SSH on port 22?

Yes, if password login is off and you use keys. Changing the port only reduces log noise; it is not a real security measure. Keys and a firewall matter far more.

I locked myself out. What now?

Use the web console or VNC console in your provider's panel, which does not depend on SSH, and fix the SSH configuration or UFW rules from there. This is why you should keep a working session open while changing these settings.

Do I need Fail2ban if I disabled passwords?

It is optional. It does not add much protection against key-only SSH, but it is useful if you also run other login-protected services such as a web panel.

Should I use a different user for each application?

Ideally yes. Running every service as its own unprivileged user limits the damage if one application is compromised.

How often should I update?

Leave security updates automatic and log in once a week or two to run sudo apt update && sudo apt upgrade and check reboot-required.