{"id":48,"date":"2026-09-06T11:24:13","date_gmt":"2026-09-06T11:24:13","guid":{"rendered":"https:\/\/nodeguard.io\/blog\/?p=48"},"modified":"2026-10-17T21:58:17","modified_gmt":"2026-10-17T19:58:17","slug":"how-to-secure-a-linux-vps","status":"publish","type":"post","link":"https:\/\/nodeguard.io\/blog\/how-to-secure-a-linux-vps\/","title":{"rendered":"How to Secure a Linux VPS: Essential Ubuntu 26.04 Hardening Guide"},"content":{"rendered":"\n

Your VPS is not anonymous. The moment an IPv4 address is assigned to your server, it becomes part of a public range that automated scanners sweep continuously. Log in to a brand-new box, run journalctl -u ssh --since \"10 minutes ago\"<\/code>, and you will usually find failed root logins already stacking up \u2014 from hosts you have never heard of, in countries you have never visited.<\/p>\n\n\n\n

\"How
Eleven minutes after provisioning: 1,284 failed login attempts, none of them personal.<\/figcaption><\/figure>\n\n\n\n

None of that is personal. It is background radiation. Bots enumerate address space, knock on port 22, try root:admin<\/code>, root:123456<\/code>, ubuntu:ubuntu<\/code>, and move on. The overwhelming majority of compromised servers are not victims of clever attacks; they are victims of defaults left untouched.<\/p>\n\n\n\n

The good news is that the fix is boring and finite. You can secure a Linux VPS to a genuinely respectable baseline in about thirty minutes, and most of that time is spent waiting for apt<\/code> to finish. This guide walks through the sequence we would follow on any new Ubuntu or Debian box, with the reasoning behind each step, because a checklist you understand is one you will actually maintain.<\/p>\n\n\n\n

Tested on Ubuntu 26.04 LTS. Every command below also works unchanged on Ubuntu 24.04 LTS and Debian 13 except where noted.<\/em><\/p>\n\n\n\n

Start From a Clean, Current Image<\/h2>\n\n\n\n

Security begins before your first SSH session. When you deploy, choose a current LTS release rather than whatever is familiar \u2014 Ubuntu 26.04 LTS or Debian 13 both carry years of security support ahead of them, which means patches keep arriving without a distribution upgrade in the middle of your busiest quarter. An OS approaching end of life is a slow-motion vulnerability.<\/p>\n\n\n\n

If your provider offers SSH key injection at deploy time, use it. Every NodeGuard Cloud VPS<\/a> can be provisioned with your public key already in place, which means the server never has a password-authenticated root account exposed to the internet, not even for the ten minutes it takes you to configure one. That closes the single most common window of exposure entirely.<\/p>\n\n\n\n

Patch Before You Do Anything Else<\/h2>\n\n\n\n

Images are snapshots. Even a freshly published one was built days or weeks ago, and the packages inside it are frozen at that moment. Your first command should always be:<\/p>\n\n\n\n

sudo apt update && sudo apt full-upgrade -y\nsudo reboot\n<\/code><\/pre>\n\n\n\n
full-upgrade<\/code> rather than upgrade<\/code> matters here: it allows packages to be added or removed when dependencies changed, which is exactly what happens with kernel and library updates. Reboot afterward if the kernel was replaced \u2014 a patched kernel sitting on disk while the vulnerable one is still running protects nobody.<\/p>\n\n\n\n
Create a Non-Root User With sudo<\/h2>\n\n\n\n
Working as root is a habit worth breaking. Not because root is inherently dangerous, but because it removes the pause between intent and consequence. A mistyped rm -rf<\/code> under a normal account throws a permission error; the same command as root does exactly what you asked.<\/p>\n\n\n\n
adduser alex\nusermod -aG sudo alex\nrsync --archive --chown=alex:alex ~\/.ssh \/home\/alex\n<\/code><\/pre>\n\n\n\n
That last line copies your existing authorized key to the new user before you lock root out \u2014 skip it and you will lock yourself out instead. Open a second terminal<\/strong> and confirm you can log in as the new user and run sudo -v<\/code> successfully. Do not close your original session until that works. This is the single most common way people strand themselves on a fresh server.<\/p>\n\n\n\n
Lock Down SSH<\/h2>\n\n\n\n
SSH is the front door, and it deserves the most attention. Edit \/etc\/ssh\/sshd_config<\/code> or, better, drop a file into \/etc\/ssh\/sshd_config.d\/99-hardening.conf<\/code> so your changes survive package upgrades cleanly. Every directive here is documented in the OpenSSH manual<\/a>.<\/p>\n\n\n\n
PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPubkeyAuthentication yes\nMaxAuthTries 3\nX11Forwarding no\nAllowUsers alex<\/code><\/pre>\n\n\n\n
If you have a static IP or connect through a VPN<\/a>, tighten it further with AllowUsers alex@your.static.ip<\/code> so SSH only answers from an address you control.<\/p>\n\n\n\n
Why key-only authentication is non-negotiable<\/h3>\n\n\n\n
A strong password is guessable given enough attempts; a 4096-bit RSA or Ed25519 key is not, in any timeframe that matters. Turning off password authentication does not merely make brute-force attacks harder \u2014 it makes them structurally impossible. The bots will keep knocking, and every attempt will fail at the protocol level before a password is ever evaluated.<\/p>\n\n\n\n
Generate your key locally, never on the server:<\/p>\n\n\n\n
ssh-keygen -t ed25519 -C \"workstation-2026\"\nssh-copy-id alex@your-server-ip\n<\/code><\/pre>\n\n\n\n
Changing the port, and one modern gotcha<\/h3>\n\n\n\n
Moving SSH off port 22 is not real security \u2014 a port scan finds it in seconds \u2014 but it does cut log noise by an enormous margin, which makes genuine anomalies visible. If you change it, be aware of a change in recent releases: Ubuntu 24.04 and 26.04 use socket activation for SSH.<\/strong> The Port<\/code> directive in sshd_config<\/code> is ignored, because systemd<\/code> owns the listening socket. Setting a new port and reloading will appear to work and then refuse connections.<\/p>\n\n\n\n
The most reliable fix is to bypass socket activation entirely:<\/p>\n\n\n\n
sudo systemctl disable --now ssh.socket\nsudo systemctl enable --now ssh.service\nsudo ss -tulpn | grep sshd\n<\/code><\/pre>\n\n\n\n
That final verification step is the important one. Always confirm the daemon is listening where you think it is, from a second session, before you disconnect.<\/p>\n\n\n\n
Put a Default-Deny Firewall in Front<\/h2>\n\n\n\n
A firewall’s job is not to block known-bad traffic. It is to permit only known-good traffic, so that a service you forgot you installed cannot quietly accept connections from the world.<\/p>\n\n\n\n
sudo ufw default deny incoming\nsudo ufw default allow outgoing\nsudo ufw allow 2222\/tcp    # your SSH port \u2014 add this FIRST\nsudo ufw allow 80,443\/tcp\nsudo ufw enable\nsudo ufw status verbose\n<\/code><\/pre>\n\n\n\n
Add the SSH rule before enabling, every single time. UFW will warn you, and the warning is not decorative.<\/p>\n\n\n\n
Two things worth knowing. First, databases should almost never appear in this list \u2014 MariaDB, PostgreSQL, and Redis belong bound to 127.0.0.1<\/code>, reachable by your application and nothing else. Second, if you sit behind a CDN or proxy such as Cloudflare, your firewall sees the proxy’s IP rather than the visitor’s. Restore the real client IP at the web-server layer, or your logs and rate limits will be measuring the wrong thing.<\/p>\n\n\n\n
Slow Down Brute Force With Fail2Ban<\/h2>\n\n\n\n
Even with key-only SSH, repeated failed attempts consume resources and bury real events in noise. Fail2Ban<\/a> reads your logs and firewalls off repeat offenders automatically.<\/p>\n\n\n\n
sudo apt install fail2ban -y\n<\/code><\/pre>\n\n\n\n
Create \/etc\/fail2ban\/jail.local<\/code> \u2014 never edit jail.conf<\/code>, which package updates overwrite:<\/p>\n\n\n\n
[DEFAULT]\nbantime  = 1h\nfindtime = 10m\nmaxretry = 5\nbackend  = systemd<\/code><\/pre>\n\n\n
[sshd]<\/p>\n\n\n\n
enabled = true port = 2222<\/p>\n\n\n\n
On current Ubuntu and Debian releases the systemd<\/code> backend matters, because journald has largely replaced flat log files. Check your work with sudo fail2ban-client status sshd<\/code>. Also whitelist your own static IP under ignoreip<\/code> if you have one \u2014 Fail2Ban does not distinguish between an attacker and a sysadmin who fat-fingered a passphrase five times.<\/p>\n\n\n\n
Turn On Automatic Security Updates<\/h2>\n\n\n\n
The gap between a vulnerability being disclosed<\/a> and being exploited at scale is now measured in hours. Manual patching cannot win that race, and most breaches exploit something that was fixed upstream weeks earlier.<\/p>\n\n\n\n
sudo apt install unattended-upgrades -y\nsudo dpkg-reconfigure --priority=low unattended-upgrades\n<\/code><\/pre>\n\n\n\n
The default configuration applies security updates only, which is the right balance \u2014 you get patched without feature updates surprising you at 3 a.m. If you want unattended reboots for kernel updates, enable Unattended-Upgrade::Automatic-Reboot<\/code> with a scheduled time, and make sure your services start cleanly on boot before you trust it.<\/p>\n\n\n\n
Reduce the Attack Surface<\/h2>\n\n\n\n
Every listening service is a potential entry point. Audit what your server is actually exposing:<\/p>\n\n\n\n
sudo ss -tulpn\nsudo systemctl list-units --type=service --state=running\n<\/code><\/pre>\n\n\n\n
Look for anything you did not deliberately install. Stock images frequently ship with services you will never use. Remove them rather than merely stopping them \u2014 an uninstalled package cannot be started by a dependency later. Where a service must run but only serves local traffic, bind it to 127.0.0.1<\/code> instead of 0.0.0.0<\/code>. That one change is worth more than most firewall rules, because it holds even if the firewall is misconfigured.<\/p>\n\n\n\n
Harden the Kernel and Shared Memory<\/h2>\n\n\n\n
A small set of sysctl<\/code> values closes off common network-level tricks. Add them to \/etc\/sysctl.d\/99-hardening.conf<\/code>:<\/p>\n\n\n\n
net.ipv4.conf.all.rp_filter = 1\nnet.ipv4.conf.all.accept_redirects = 0\nnet.ipv4.conf.all.send_redirects = 0\nnet.ipv4.conf.all.accept_source_route = 0\nnet.ipv4.icmp_echo_ignore_broadcasts = 1\nnet.ipv4.tcp_syncookies = 1\nkernel.dmesg_restrict = 1\n<\/code><\/pre>\n\n\n\n
Apply with sudo sysctl --system<\/code>. These are conservative, widely deployed settings; they will not break a normal web or application server, and they remove several classes of spoofing and reconnaissance outright.<\/p>\n\n\n\n
Secure the Application Layer<\/h2>\n\n\n\n
Server hardening is necessary but insufficient. In practice, the majority of real-world compromises on hosting infrastructure arrive through the application, not the operating system.<\/p>\n\n\n\n