A fresh VPS is a wonderful thing for about four minutes. Then the bots find it. If you watch the auth log on a brand-new public IP, the SSH brute-force attempts usually start within the hour — no targeting, no grudge, just the background radiation of the internet sweeping every address for weak passwords.
The good news: you do not need to be a security expert to be a hard target. You need about thirty minutes and a checklist. This is mine, in the order I actually do it on every new Ubuntu or Debian server, whether it is a $5 VPS or a box in my closet.
Minute 0–5: Update everything, then create your user
sudo apt update && sudo apt upgrade -y
Boring, and still the highest-value security action on this list. Most real-world server compromises are not exotic zero-days; they are old software with a public exploit and an owner who meant to patch next week.
Next, stop using root for daily work:
adduser faizan
usermod -aG sudo faizan
Everything after this point happens as your user. This is partly about safety and partly about making sudo a small moment of friction before dangerous commands — friction you will appreciate the first time you nearly type rm -rf in the wrong directory.
Minute 5–10: SSH keys, and test before you lock anything
On your laptop, not the server:
ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id faizan@YOUR_SERVER_IP
Log in with the key in a new terminal window. Only after that works, harden SSH on the server in /etc/ssh/sshd_config (or a drop-in in sshd_config.d/):
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Reload: sudo systemctl reload ssh.
The golden rule, learned from one very stupid afternoon: keep your current session open until you have proven a new one works. Locking yourself out of a remote server because you disabled passwords before testing the key is a rite of passage, but you can skip it. We cover the deeper version of this in Hardening SSH for Production Servers — including why changing the SSH port is mostly cosmetic.
Minute 10–15: Firewall — default deny, then allow
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
If you will run a web server, add it before enabling:
sudo ufw allow 'Nginx Full' # or: sudo ufw allow 80,443/tcp
ufw status verbose should now show SSH and your web ports, nothing else. The principle is simple and worth internalizing: every open port is a decision, not an accident. If a service only needs to be reachable from your app server, bind it to localhost or a private IP instead of punching a firewall hole — our PostgreSQL security guide walks through that for 5432 specifically.
Minute 15–20: Fail2ban for the brute-force noise
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
The default SSH jail on Debian/Ubuntu works out of the box: repeated failed logins get the source IP banned for a while. Check it with sudo fail2ban-client status sshd.
This does not make weak security strong — key-only SSH already did that — but it keeps the logs readable and the bots slow. If you want the CentOS-flavored walkthrough, there is one in our Fail2Ban guide.
Minute 20–25: Automatic security updates
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
This installs security patches automatically. It occasionally holds the dpkg lock for a few minutes after boot, which is why your apt install sometimes fails on a fresh machine — wait it out instead of killing the process.
Should a server reboot itself after kernel updates? My answer for small personal servers is no: schedule reboots for a time you are awake and watching. For anything more serious, that is what maintenance windows are for.
Minute 25–30: Timezone, hostname, and a baseline snapshot
Three small quality-of-life steps that pay off later:
sudo timedatectl set-timezone Asia/Kolkata
sudo hostnamectl set-hostname nextcloud-box
Sane logs need sane timestamps, and faizan@nextcloud-box in your prompt beats faizan@localhost when you have six tabs open on six machines.
Finally, if your provider offers snapshots, take one now. This baseline is your undo button. The next snapshot comes after the first big config change that works.
The whole thing as a checklist
- [ ]
apt update && apt upgrade - [ ] Non-root sudo user
- [ ] SSH key installed and tested in a new session
- [ ]
PermitRootLogin no,PasswordAuthentication no - [ ] UFW: deny incoming by default, allow only what you chose
- [ ] Fail2ban running
- [ ] Unattended-upgrades on
- [ ] Timezone + hostname set
- [ ] Baseline snapshot taken
Thirty minutes, and you are ahead of the vast majority of servers on the internet. Security after this point is mostly keeping the machine patched and being stingy with new open ports — the checklist just does not have to live in your head anymore.
Top comments (0)