Skip to content
savemores
Menu
Get 20% off

VPS & deployment

Harden a New Hostinger VPS in Ten Minutes: Keys, Firewall, Updates

Secure a new Hostinger VPS before it goes live: SSH keys, root and password logins off, UFW, Fail2ban, automatic patches and snapshots, with tested commands.

By · 20+ years in tech

Published · 9 min read

The short answer

  • 01A fresh Hostinger VPS allows root login and has no firewall rules of your own, so harden it before you deploy anything.
  • 02The minimum is: full update, a sudo user with an SSH key, root and password logins disabled, UFW allowing only 22, 80 and 443, Fail2ban, and unattended security upgrades.
  • 03On Ubuntu 24.04, put SSH settings in /etc/ssh/sshd_config.d/00-hardening.conf so they load before a cloud-init file that may enable passwords.
  • 04Docker-published ports bypass UFW, so bind container ports to 127.0.0.1.
  • 05Keep your current SSH session open until a new login works; if you do get locked out, hPanel's browser terminal still reaches the server.

Before you start: two rules

Any machine with a public IP starts receiving automated SSH login attempts within minutes of booting. Nobody is targeting you; bots sweep the entire IPv4 range all day long. The work below removes almost all of that exposure and takes around ten minutes.

Rule one: do the sections in order. Rule two: keep the SSH session you are working in open until the very end, and test every access change from a second terminal. That open session is your undo button.

Patch the system

OS templates are built in advance, so a new server is usually a few updates behind on day one.

bash
apt update && apt full-upgrade -y
reboot   # if a new kernel was installed

Create a sudo user that logs in with a key

Routine work should happen as an ordinary user with sudo rights, not as root. If you supplied an SSH key when creating the VPS, it sits in root's authorized_keys, and you can copy it across.

  1. 1Create the user and add it to the sudo group.
  2. 2Copy root's .ssh folder to the new user with the right ownership.
  3. 3If you have no key yet, generate one on your laptop and push it to the server with ssh-copy-id.
  4. 4In a second terminal, log in as deploy and run sudo -v to confirm the password works. Do not continue until both succeed.
bash
adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy/
No key yet? Create one on your laptop, then copy it up:
bash
ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id deploy@YOUR_SERVER_IP

Switch off root and password logins

On Ubuntu 24.04, leave sshd_config alone and write a drop-in file instead. There is a trap here. For each option, sshd keeps the first value it reads, and drop-in files are read in alphabetical order. Cloud images often include 50-cloud-init.conf, which turns password login on. Give your file a lower number, such as 00-, so your values win.

/etc/ssh/sshd_config.d/00-hardening.conf
bash
sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF

sudo sshd -t                  # syntax check, prints nothing when OK
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
sudo systemctl restart ssh

Firewall: open only the ports you serve

UFW is the least fiddly firewall on Ubuntu. Allow SSH before you enable it, then add the web ports. Hostinger also offers a network firewall in the VPS settings in hPanel. Running both is fine; the hPanel firewall drops traffic before it ever reaches your VM.

bash
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 --force enable
sudo ufw status verbose

Fail2ban for repeat offenders

Once password login is off, brute force cannot succeed. Fail2ban is still worth having: it bans noisy scanners and keeps your auth log readable. The stock SSH jail is all you need.

bash
sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Automatic security patches

Unattended-upgrades applies security updates daily and leaves everything else alone. Most Ubuntu images ship with it; these commands make sure it is installed and switched on.

bash
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades   # choose "Yes"

Snapshots are not backups

Now that the server is clean, take a snapshot in hPanel, and take another before any risky upgrade. A restore takes minutes.

A snapshot lives with the same provider and the same account as the server, so it is not an off-site backup. Dump your database on a schedule and ship the file somewhere else, such as object storage or another machine, so one account problem cannot take out the server and its backup together.

  • Snapshot before major upgrades or configuration changes.
  • Nightly database dump from cron, stored off the server.
  • Restore one backup as a test. Until you have restored it, it is a hope, not a backup.

Verify it worked

Run these from a new terminal. Every line should match the expected result before the server takes real traffic.

  • System fully updated
  • Non-root sudo user with an SSH key
  • Root and password logins disabled, tested from a fresh session
  • UFW enabled with only 22, 80 and 443 open
  • Docker ports bound to 127.0.0.1
  • Fail2ban running
  • Unattended security upgrades enabled
  • Clean snapshot taken; off-server database backups scheduled
On the server:
bash
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
# expect: permitrootlogin no / passwordauthentication no

sudo ufw status verbose
# expect: default deny incoming; only OpenSSH, 80/tcp, 443/tcp allowed

sudo fail2ban-client status sshd
# expect: the sshd jail is listed and running

sudo docker ps
# if Docker is installed: published ports should show 127.0.0.1:..., not 0.0.0.0:...
From your laptop:
bash
ssh root@YOUR_SERVER_IP      # expect: Permission denied
ssh deploy@YOUR_SERVER_IP    # expect: logs in with your key

Next steps

Point your domain at the box with the DNS guide, deploy a Next.js app, then stop deploying by hand with GitHub Actions push-to-deploy.

Questions people ask

Is a Hostinger VPS secure out of the box?

The platform layer is, with DDoS filtering and isolated KVM virtualization, but the operating system is your responsibility. A fresh image permits root login and has no firewall rules of your own, so harden it before deploying.

Should I move SSH off port 22?

It is not worth it for most people. It cuts log noise but adds little security once passwords are off, and on Ubuntu 24.04 SSH uses socket activation, so you would also have to edit the ssh.socket unit. Keys plus Fail2ban on port 22 is the boring, correct choice.

I locked myself out. How do I get back in?

Open the browser terminal in hPanel's VPS dashboard. It connects through the console rather than SSH, so you can repair the sshd config or firewall rules from there.

Do I need UFW if I use the hPanel firewall?

Not strictly, but running both is sensible. The hPanel firewall filters traffic before it reaches the VM, and UFW keeps protecting the server if you ever move it to another provider.

Independent site, not Hostinger. Buy through my links and Hostinger pays me a referral fee; your price is the same or lower. How that works.