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

URL: https://www.savemores.store/vps/secure-new-vps
Author: Mr. Ahmed · Published 2026-10-17 · Updated 2026-10-17 · VPS & deployment

## Short answer

- A fresh Hostinger VPS allows root login and has no firewall rules of your own, so harden it before you deploy anything.
- The 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.
- On 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.
- Docker-published ports bypass UFW, so bind container ports to `127.0.0.1`.
- Keep 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.

> From the bench: Take a snapshot in hPanel before you change SSH or firewall settings, even on a blank server. If you lock yourself out, the browser terminal in hPanel's VPS dashboard connects through the console rather than SSH, so you can still fix things. But a snapshot is faster than debugging a broken sshd config at 2 a.m.

## 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. Create the user and add it to the sudo group.
2. Copy root's `.ssh` folder to the new user with the right ownership.
3. If you have no key yet, generate one on your laptop and push it to the server with `ssh-copy-id`.
4. In 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
```

> From the bench: This is the step that locks people out. Run `sshd -t` before every restart, and open a brand-new terminal to log in as `deploy` before you close the old one. If the new login fails, repair it from the session that is still connected.

## 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
```

> From the bench: Docker writes its own iptables rules and walks straight past UFW for published ports. A container started with `-p 5432:5432` is open to the internet even though `ufw status` says otherwise. Publish to loopback instead, for example `-p 127.0.0.1:5432:5432`. I check this on every server that runs Docker, because the firewall output actively misleads you.

## 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](https://www.savemores.store/vps/point-domain-dns), [deploy a Next.js app](https://www.savemores.store/vps/deploy-nextjs), then stop deploying by hand with [GitHub Actions push-to-deploy](https://www.savemores.store/vps/github-actions-deploy).

## FAQ

### 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.