Mastodon

Day 9: Hardening the Fortress — Securing Your Linux VPS - Step By Step Guide

Day 9 is all about securing our Linux VPS after you’ve bought and configured your VPS (Day 7) and pointed your domain to it (Day 8). It feels like a private island, but on the internet, there is no such thing as “hidden.” The moment your IP address goes live, it is being scanned. This

$ ssh-copy-id -i ~/.ssh/ed25519.pub username@12.34.56.78 OR manually copy

ssh username@hostname 
echo 'ssh-ed25519 AAAAC3N.....ED' >> ~/.ssh/authorized_keys

Adding to ssh agent

eval “$(ssh-agent -s)” $ ssh-add ~/.ssh/ed25519

Security isn’t a “set and forget” task; it’s a fundamental state of engineering. Within minutes of provisioning, bots from around the globe are already attempting brute-force attacks on your SSH port.

The “War Zone” Reality

Don’t believe me? Once you log in, run this command to see the failed login attempts on your fresh system:

sudo journalctl -u ssh | grep "Failed password"

You will likely see hundreds of lines. This is why we harden the system immediately.

1. The First Rule: Kill the Root Login

Logging in as root is like walking around with a master key taped to your forehead. If you lose that session, you lose the whole system.

Create a Sovereign User

First, create a normal user with a name that isn’t easy to guess (avoid admin or devops).

sudo adduser andrei

Grant this user administrative powers by adding them to the sudo group:

sudo usermod -aG sudo andrei

Now, test it without closing your root session (stay safe!):

su - andrei
sudo whoami
# Should return 'root'

Lockdown Root

Now we tell the SSH daemon that root is no longer welcome to log in directly. Open the config:

sudo nano /etc/ssh/sshd_config

Find and change the following lines:

PermitRootLogin no
PasswordAuthentication yes

Note: We keep PasswordAuthentication “yes” for just a moment until we verify our SSH keys in the next steps.

2. Shifting the Goalposts: Changing the SSH Port

Standard SSH runs on Port 22. Every bot in existence scans Port 22. While “Security by Obscurity” isn’t a complete solution, changing the port reduces log noise by 99%.

In the same /etc/ssh/sshd_config, find #Port 22, uncomment it, and pick a high number (e.g., 2222 or 49152):

Port 54321

Apply changes:

sudo systemctl restart ssh

Warning: Before you log out, ensure your firewall allows this new port, or you will be locked out!

3. Building the Wall: UFW (Uncomplicated Firewall)

On Linux, we use ufw to ensure only the doors we want are open. We want to be strict: deny everything by default, allow only what we need.

sudo ufw app list sudo ufw allow ‘OpenSSH’ ->

# Allow our new custom SSH port
sudo ufw allow 54321/tcp

# Allow web traffic (Day 8 stuff)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable

$ sudo ufw default deny incoming $ sudo ufw default allow outgoing Check the status: sudo ufw status verbose.

4. Banning the Persistent: Fail2Ban

Fail2Ban is like a digital bouncer. It monitors your logs, and if it sees an IP address failing to log in 3-5 times, it updates the firewall to block that IP for a set amount of time.

Install it:

sudo apt install fail2ban

The default configuration is usually enough to protect SSH, but you can verify it’s running:

sudo fail2ban-client status sshd

5. Automated Hygiene: Updates & Unattended Upgrades

Security vulnerabilities are discovered every day. If you don’t patch, you are vulnerable.

Manual Update:

sudo apt update && sudo apt upgrade -y

Automated Security Patches: Install unattended-upgrades so your system installs security fixes even while you sleep.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

6. Fine-Grained SSH Control

In your /etc/ssh/sshd_config, you can be even more specific about who gets in.

Limit to specific users:

AllowUsers andrei

Multi-Factor (The Pro Setup): Eventually, you want to require both a physical SSH Key and a password.

AuthenticationMethods publickey,password
PubkeyAuthentication yes

Optional: Experimental Hardening

If you want to go deeper, you can experiment with:

  • Port Knocking: The SSH port stays closed until you “knock” on a specific sequence of other ports.
  • MFA (Google Authenticator): Adding a 6-digit TOTP code to your SSH login.
  • Kernel Hardening: Using sysctl to prevent IP spoofing and redirect attacks.

Summary Checklist

  1. New sudo user created?
  2. Root login disabled?
  3. Custom SSH port set?
  4. UFW Firewall active?
  5. Fail2Ban installed?
  6. Unattended upgrades enabled?

By following these steps, you’ve moved from a “soft target” to a “hardened fortress.” You aren’t just running a server; you are practicing Sovereign Engineering.

Next up in Day 10: We dive deep into the magic of SSH—Keys, Configs, and Tunnels.

Privacy is Peace. Engineering is Freedom.

https://www.kkyri.com/p/how-to-secure-your-new-vps-a-step-by-step-guide

Create non root user to login and

sudo adduser youruser

sudo usermod -aG sudo username

switch to new user su - username sudo whoami

Edit sudoers file?

disable root login

set good root password

  • change default ssh port

add sudo

ssh key authentication

Firewall ufw/nftables fail2ban

updates

sudo apt update sudo apt upgrade

unattended upgrades?

Other stuff ;) SSH security later

AllowUsers user1 user2

AuthenticationMethods publickey,password PasswordAuthentication yes PubkeyAuthentication yes

Optional stuff you can experient

Some people use