Secure a new Linux VPS in 10 minutes

Step 1: Update every package

Images are built ahead of time, so a new server is usually a few updates behind. Install them before anything else. The last line reboots only if a new kernel or core library needs it. Setting the time zone to IST makes logs and scheduled jobs line up with your working day.

apt update && apt full-upgrade -y
apt autoremove -y
timedatectl set-timezone Asia/Kolkata
[ -f /var/run/reboot-required ] && reboot

dnf upgrade -y
timedatectl set-timezone Asia/Kolkata
dnf needs-restarting -r || reboot

If the server reboots, wait a minute and log in again as root.

Step 2: Create a user with sudo rights

Working as root means one mistyped command can damage the whole system, and root is the account every bot tries first. Create your own user, give it administrator rights through sudo, and copy root's SSH key to it. Replace deploy with the name you want.

apt install -y sudo                 # already present on Ubuntu
adduser deploy                      # set a strong password when asked
usermod -aG sudo deploy

mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh && chmod 600 /home/deploy/.ssh/authorized_keys

useradd -m -s /bin/bash deploy
passwd deploy                       # set a strong password
usermod -aG wheel deploy

mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh && chmod 600 /home/deploy/.ssh/authorized_keys
restorecon -R /home/deploy/.ssh     # fix SELinux labels on the copied key

Now open a second terminal on your computer and check that the new account works, including sudo. It should print root after asking for the password you just set:

ssh deploy@203.0.113.42
sudo whoami

Keep that password somewhere safe. With password logins turned off in the next step, you'll only need it for sudo and for the browser Console.

Step 3: Turn off root and password logins over SSH

With your own user working, close the two doors bots knock on: logging in as root, and logging in with a password. The settings go in a small file of their own, so package updates never overwrite them. It's named 00-… because SSH uses the first value it reads, which puts it ahead of distribution defaults such as Ubuntu's 50-cloud-init.conf.

cat > /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF
sshd -t && systemctl reload ssh

cat > /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF
sshd -t && systemctl reload sshd

sshd -t checks the syntax first, so a typo can't stop SSH from starting. Confirm what the server is actually using:

sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication) '
# expected:  permitrootlogin no   /   passwordauthentication no

Step 4: Add a firewall and fail2ban

The firewall drops everything you haven't explicitly allowed. fail2ban watches the SSH log and bans an address for an hour after five failed attempts in ten minutes, which keeps logs readable and slows down scanners.

1. Turn on the firewall

   Allow SSH first, then web traffic only if this server will host websites.

   Ubuntu / Debian AlmaLinux / Rocky

   apt install -y ufw                  # Debian doesn't ship it
   ufw default deny incoming
   ufw default allow outgoing
   ufw allow 22/tcp
   ufw allow 80,443/tcp                # web servers only
   ufw enable
   ufw status verbose

   Using Docker? Ports published with -p skip ufw's rules entirely. Publish internal services on 127.0.0.1 only (for example -p 127.0.0.1:5432:5432) and put a reverse proxy in front of anything public.

2. Install and configure fail2ban

   Ubuntu / Debian AlmaLinux / Rocky

   apt install -y fail2ban python3-systemd

   Then, on either system, write your settings to jail.local, which updates never touch. Put your office or home IP (our what's my IP tool shows it) in ignoreip so you can't ban yourself:

   cat > /etc/fail2ban/jail.local <<'EOF'
   [DEFAULT]
   bantime  = 1h
   findtime = 10m
   maxretry = 5
   ignoreip = 127.0.0.1/8 ::1 198.51.100.7
   
   [sshd]
   enabled = true
   backend = systemd
   EOF
   systemctl enable fail2ban && systemctl restart fail2ban
   fail2ban-client status sshd

   backend = systemd reads the system journal, so it works on images that don't write /var/log/auth.log, including Debian 12.

Step 5: Install security updates automatically

Most break-ins use flaws that were patched weeks earlier. Let the server install security updates on its own every day; you still run full upgrades yourself when convenient.

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades  # choose "Yes"
cat /etc/apt/apt.conf.d/20auto-upgrades     # both lines should end in "1"

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

dnf install -y dnf-automatic
sed -i -e 's/^upgrade_type.*/upgrade_type = security/' \
  -e 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer      # shows the next run

Step 6: Turn on backups, then run the checklist

Security also means being able to recover. Every VPS includes 3 on-demand snapshots. Take one now from the client area: it's a clean, hardened starting point you can roll back to in minutes. For protection against mistakes and bad updates, add the backups add-on (+20% of the plan price), which keeps daily copies for 14 days. See VPS add-ons.

Finally, confirm each step stuck. Run these as your new user:

VPS security troubleshooting

sudo fail2ban-client -t
sudo journalctl -u fail2ban -n 30 --no-pager

sudo fail2ban-client set sshd unbanip 198.51.100.7