Setting Up a VPS in 2026 — Secure It From Scratch.

Order a VPS, pick Ubuntu 24.04 as the operating system, and choose a data-center region close to your users (this one is in Mumbai). Once it boots, your provider's dashboard shows the two things you need: the public IP address and the root password.

VPS Dashboard Click to expand

SSH (Secure Shell) is the protocol you use to securely control a remote server. The ssh client ships by default on Linux, macOS and Windows. Open a terminal on your own computer and connect using the server's IP — here root is the username Hostinger gave us (yours may differ), and the part after @ is the IP:

ssh root@62.72.59.218

The very first time, SSH asks you to verify the server's fingerprint. Type yes to trust it — it's saved on your machine and checked on every future connection:

Host Fingerprint Prompt Click to expand

Enter the root password from your dashboard when prompted. You're now inside the server — the prompt changes to something like root@srv416761:~#.

The first thing to do on any new server is refresh the package list and upgrade everything that's outdated. Ubuntu is Debian-based, so we use APT:

apt update
apt upgrade -y

apt update only refreshes the list of available packages from the repositories — it doesn't change anything installed. apt upgrade then installs the newer versions. On a Red Hat–based distro (CentOS, Fedora) you'd swap apt for dnf.

Some upgrades (like a new kernel) need a reboot. Check for the marker file — if it exists, a reboot is required:

cat /var/run/reboot-required

You can reboot straight from your provider's dashboard (the Reboot VPS button you saw earlier), or over SSH:

reboot

Living as root full-time is risky — one wrong command runs with unlimited power. Create a regular user instead. You'll be asked to set a password (make it different from root's) and can press Enter through the optional details:

adduser thapa

adduser Click to expand

By default this user can't run admin commands. Add it to the sudo group so it can — only when prefixed with sudo — then confirm:

usermod -aG sudo thapa
groups thapa

Grant sudo Click to expand

Seeing thapa : thapa sudo users confirms it worked. Exit and log back in as the new user:

ssh thapa@62.72.59.218

As a normal user you no longer have automatic admin powers. Run an admin command directly and you'll hit a wall — that's the security working as intended:

Permission Denied Click to expand

The fix is simply to prefix admin commands with sudo and enter your user's password when asked:

sudo apt update

Passwords can be brute-forced; SSH keys effectively can't. On your own machine (not the server), generate a modern ed25519 key pair. Press Enter to accept the default location and optionally set a passphrase:

ssh-keygen -t ed25519 -C "you@example.com"

# On a legacy system without ed25519 support, use RSA:
ssh-keygen -t rsa -b 4096 -C "you@example.com"

ssh-keygen Click to expand

Keys are stored in your .ssh folder (C:\Users\You\.ssh on Windows, ~/.ssh on macOS & Linux). You'll see two files — the distinction is critical:

Key Files Click to expand

Now put the public key on the server. The easiest way is ssh-copy-id (macOS, Linux and Git Bash):

ssh-copy-id thapa@62.72.59.218

If you'd rather do it by hand (or you're on plain Windows PowerShell): connect as the non-root user, create the .ssh folder, and paste your public key into an authorized_keys file:

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
# paste the full contents of id_ed25519.pub, then Ctrl+O, Enter, Ctrl+X

Now test it — you should log straight in with no password prompt (or just your key's passphrase):

ssh thapa@62.72.59.218

If you set a passphrase on your key, the OpenSSH Authentication Agent can remember it so you don't retype it every connection. The quickest way is two commands in PowerShell (as administrator):

Get-Service -Name ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Prefer a GUI? Open Services from Windows Search, find OpenSSH Authentication Agent, right-click it and choose Properties:

Services → Properties Click to expand

Set Startup type to Automatic, click Start, then OK:

Startup: Automatic Click to expand

Then add your key to the agent (only needed if you used a non-default key name or a passphrase):

ssh-add $env:USERPROFILE\.ssh\id_ed25519

With key login confirmed, it's time to slam the door on passwords and root. On the server, open the SSH daemon config:

sudo nano /etc/ssh/sshd_config

Find these lines, uncomment them if needed, and set them like so — this keeps key auth on and turns password auth off:

sshd_config Click to expand

PubkeyAuthentication yes
PasswordAuthentication no

On Hostinger that file is 50-cloud-init.conf inside /etc/ssh/sshd_config.d/ (note: sshd_config.d, not ssh_config.d). Look at it:

cd /etc/ssh/sshd_config.d/
ls
sudo cat 50-cloud-init.conf

The Override File Click to expand

Edit it and change its yes to no so it stops overriding you:

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf
# set: PasswordAuthentication no

Now forbid root from logging in over SSH entirely. Back in the main config, find PermitRootLogin and set it to no:

PermitRootLogin no Click to expand

PermitRootLogin no

Save each file (Ctrl+O, Enter, Ctrl+X), then restart SSH to apply everything:

sudo systemctl restart ssh
# the service may be named sshd on CentOS/Fedora

A firewall closes every port except the ones you explicitly open. Ubuntu (and Hostinger) ship with UFW, the Uncomplicated Firewall. If yours doesn't have it: sudo apt install ufw. Check its current state:

sudo ufw status

It'll likely report inactive. Set a default-deny posture — block all incoming, allow all outgoing:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Default Deny Click to expand

Allow SSH so you can keep managing the server (if you changed the SSH port, use sudo ufw allow <port-number> instead):

sudo ufw allow OpenSSH

Allow OpenSSH Click to expand

We'll be hosting websites later, so open the web ports too, then turn the firewall on:

sudo ufw allow http   # same as 80/tcp
sudo ufw allow https  # same as 443/tcp
sudo ufw enable

Finally, confirm exactly what's open:

sudo ufw status

Firewall Active Click to expand