You just spun up your first Linux server, and right now it is a fresh machine with a public IP that bots are already knocking on. This guide is for beginners who want to secure a new VPS in the first hour, before it runs any real workload. You will get a clear, ordered checklist with the exact commands, plus an explanation of what each one does and why it matters.
The examples below assume Ubuntu or Debian, which is what most people run on a Linux VPS. The same hardening principles apply to a Windows VPS, though the specific tools differ. Work through the steps in order, and keep a second terminal open the whole time so you never lock yourself out.
Why a brand-new VPS is a target
Within minutes of a server going online, automated scanners start trying to log in over SSH using common usernames and leaked passwords. They are not targeting you personally. They sweep entire IP ranges around the clock. A default server that lets root log in with a password is the single easiest thing for them to crack.
The good news is that a handful of changes removes almost all of that risk. The plan is simple: stop using passwords, stop logging in as root, patch the system, close unused ports, and put a tripwire in front of what remains. Do it in this order.
Step 1: Create a non-root user
Root can do anything, including destroy the system with one mistyped command. You want a normal user for day-to-day work and root privileges only when you deliberately ask for them with sudo. Log in as root the first time, then create your account:
- adduser deploy creates a user called deploy and prompts you for a password. Pick a strong one, even though you will soon stop logging in with it.
- usermod -aG sudo deploy adds that user to the sudo group so it can run admin commands when needed.
On some distributions the admin group is called wheel instead of sudo. Once the user exists, open a second terminal and confirm you can log in as deploy and run something like sudo apt update before you go any further. Never lock yourself out by editing SSH settings while you only have one way in.
Step 2: Switch to SSH keys and disable password login
An SSH key pair is far stronger than any password a person will remember. You keep a private key on your own computer and put the matching public key on the server. Only the holder of the private key can log in, and there is nothing for a bot to guess.
Generate and install your key
On your local machine, not the server, generate a key:
- ssh-keygen -t ed25519 -C "you@example.com" creates a modern, fast key pair. Press enter to accept the default location and add a passphrase when asked, so the key is useless if your laptop is stolen.
- ssh-copy-id deploy@your-server-ip uploads the public half to your new user's account. If ssh-copy-id is not available, paste the contents of your local ~/.ssh/id_ed25519.pub into ~/.ssh/authorized_keys on the server.
Now open a fresh terminal and run ssh deploy@your-server-ip. If it logs you in without asking for the server password, your key works. Confirm this before you go further, because you are about to turn passwords off.
Turn off password and root login
With key access proven, close the two doors bots rely on. Edit the SSH daemon config with sudo nano /etc/ssh/sshd_config and set these three lines, removing any leading # so they take effect:
- PermitRootLogin no stops anyone from logging in directly as root over SSH.
- PasswordAuthentication no forces key-based login and makes password guessing pointless.
- PubkeyAuthentication yes makes sure key logins stay enabled.
Save the file and reload the service with sudo systemctl restart ssh (the service is called sshd on some systems). Keep your current session open, then open a brand new one to test that key login still works. If something is wrong, your existing session is the safety net you use to fix it. Once confirmed, password and root brute-force attempts simply bounce off.
Step 3: Update now, then update automatically
A fresh image is rarely fully patched. Bring everything current straight away:
- sudo apt update refreshes the list of available packages.
- sudo apt upgrade installs the newer versions, including security fixes.
Patching once is not enough, because new vulnerabilities appear constantly. Turn on unattended security updates so critical fixes install on their own:
- sudo apt install unattended-upgrades installs the tool.
- sudo dpkg-reconfigure unattended-upgrades and choose Yes to enable automatic security updates.
This handles the most important category of fixes without you remembering to log in. Reboot occasionally, since some kernel and library updates only take full effect after a restart.
Step 4: Close unused ports with a firewall
A firewall decides which traffic is allowed to reach your server. The safe default is to block everything inbound, then open only the ports you actually use. Ubuntu ships with ufw, an approachable front end for exactly this:
- sudo ufw default deny incoming and sudo ufw default allow outgoing set a deny-by-default posture.
- sudo ufw allow OpenSSH keeps your management port open so you do not lock yourself out.
- Add web ports only if you run a site: sudo ufw allow 80/tcp and sudo ufw allow 443/tcp.
- sudo ufw enable switches it on, and sudo ufw status shows the active rules.
The rule to remember is that every open port is a possible entrance. Open only what a real service needs, and close it again the moment that service is gone.
Step 5: Add fail2ban and take backups
Even with keys only, bots will keep hammering the SSH port. fail2ban watches your logs and temporarily bans any IP that fails to authenticate too many times. Install it with sudo apt install fail2ban. It enables a sensible SSH jail out of the box, and you can confirm activity with sudo fail2ban-client status sshd. That single package quietly absorbs the constant background noise of login attempts.
Finally, hardening is not the same as recovery. A compromised, corrupted, or accidentally wiped server is only a real problem if you cannot restore it. Set up backups before you need them:
- Enable your provider's snapshot feature for full-machine restore points.
- For file-level backups, tools like restic or borg create encrypted, versioned copies you can send to separate storage.
- Store at least one copy off the server itself, and test a restore so you know it actually works.
Your first-hour checklist
Run through these in order and you have covered the essentials that stop the overwhelming majority of attacks:
- Create a non-root user with sudo access.
- Set up SSH key login and confirm it works.
- Disable root login and password authentication.
- Update the system and enable automatic security updates.
- Turn on ufw and allow only the ports you use.
- Install fail2ban and configure real backups.
None of this makes a server invincible, but it moves you from an easy, opportunistic target to one that automated attacks give up on. Do it once, keep updates flowing, and check your firewall rules whenever you add a new service. If you are still comparing plans and specs before you commit, our pricing page lays out the options, and if you want the wider view of how a VPS stacks up against other setups, read our breakdown of shared hosting, VPS and game servers. Secure the box first, then build on it with confidence.