You just spun up a fresh VPS. Ubuntu 24.04, root access, public IP. Within minutes of that server going live, automated bots are already scanning it. They're trying default credentials, probing open ports, and looking for any way in.
Most people skip the hardening step. They install their application, open the ports they need, and move on. The server works. Everything seems fine. Until it doesn't — and by then, the damage is done.
Hardening a VPS isn't optional. It's the difference between a production server and a liability. And with Ansible, you can do it in under 10 minutes, every time, consistently, without missing a step.
What Happens to an Unhardened Server
A fresh Ubuntu VPS with default settings has several problems that attackers exploit within hours of provisioning.
SSH accepts password authentication. This means anyone on the internet can attempt to log in by guessing passwords. Automated botnets run millions of password combinations against SSH servers continuously. If your root password is anything less than perfectly random, it's a matter of time.
SSH runs on port 22. Every scanner on the internet hits port 22 first. Moving SSH to a non-standard port doesn't make it secure by itself, but it eliminates 99% of automated noise. The bots that scan port 22 rarely bother scanning all 65,535 ports.
The firewall is wide open. Ubuntu doesn't enable UFW by default. Every service you install is accessible from the internet unless you explicitly block it. That database you installed for your application? It's listening on its default port, exposed to the world.
Root login is enabled. The root account has unlimited access to everything on the server. If someone compromises root, they own the machine completely. Disabling root login and using a regular user with sudo forces attackers to compromise two layers instead of one.
The Hardening Checklist
A properly hardened VPS has five layers of protection. Each one is simple on its own. Together, they make your server dramatically harder to compromise.
SSH key-only authentication disables password login entirely. You generate a key pair, put the public key on the server, and SSH only accepts connections from someone holding the matching private key. No password to guess, no brute force to attempt.
Non-standard SSH port moves your SSH service off port 22 to something like 2222 or any other unused port. This is security through obscurity — it doesn't stop a determined attacker, but it stops the automated scanners that generate 99% of SSH attacks.
Root login disabled means nobody can SSH in as root, even with a valid key. You create a deploy user with sudo access instead. This adds a layer — even if someone gets in, they need to escalate privileges before they can do real damage.
UFW firewall with a deny-all default policy means every port is closed unless you explicitly open it. You allow SSH on your custom port, HTTP on 80, and HTTPS on 443. Everything else is blocked. No surprises, no forgotten services listening on random ports.
Automatic security updates keep the operating system patched without manual intervention. Ubuntu's unattended-upgrades package handles this — critical security patches are applied automatically so you're not vulnerable to known exploits between manual maintenance windows.
Why Ansible Changes Everything
You could do all of this manually. SSH into the server, edit configuration files, restart services, configure the firewall. It takes about 30 minutes if you know what you're doing, and you'll probably forget something.
Ansible automates the entire process. You write the configuration once as a playbook — a YAML file that describes what the server should look like — and Ansible makes it happen. Every time. On every server. Identically.
The first benefit is consistency. When you harden a server manually, the tenth server you configure won't be identical to the first. You'll forget a step, mistype a configuration value, or skip something because you're in a rush. Ansible doesn't forget. It runs the same steps in the same order with the same values every time.
The second benefit is speed. A playbook that takes 30 minutes to execute manually runs in under 10 minutes with Ansible. You type one command, go make coffee, and come back to a hardened server.
The third benefit is idempotency. You can run the same playbook against the same server multiple times and it only changes what needs changing. If SSH is already configured correctly, Ansible skips that step. This makes Ansible perfect for both initial setup and ongoing maintenance — run the same playbook monthly to verify everything is still configured correctly.
What an Ansible Hardening Playbook Looks Like
An Ansible hardening playbook is organized into roles — modular units that each handle one aspect of the configuration. A typical hardening playbook has roles for SSH configuration, firewall setup, user creation, and automatic updates.
The SSH role modifies the sshd_config file to disable password authentication, disable root login, and change the port. It also ensures only the specified SSH keys are authorized. Then it restarts the SSH service to apply the changes.
The firewall role installs UFW, sets the default policy to deny all incoming traffic, and opens only the ports you specify. It enables the firewall and verifies it's running correctly.
The user role creates a deploy user with sudo privileges, sets up SSH key authentication for that user, and configures sudo to not require a password for the deploy user. This gives you a secure, non-root way to administer the server.
The updates role installs and configures unattended-upgrades for automatic security patches. It sets the schedule, configures which package sources to auto-update, and optionally enables automatic reboots when kernel updates require them.
When you run the playbook, Ansible connects to the server over SSH, executes each role in order, and reports back what it changed. The output shows you exactly what happened — which files were modified, which services were restarted, which packages were installed.
Beyond the Basics
The five-layer hardening described above is the minimum. Depending on what you're running on the server, additional hardening steps might include fail2ban for automatic IP banning after failed login attempts, log monitoring for detecting suspicious activity, Docker containerization to isolate applications from the host system, and a reverse proxy like Nginx to sit between the internet and your application.
Each of these can be added as additional Ansible roles. The playbook grows as your security requirements grow. And because each role is modular, you can mix and match — a password manager server gets different roles than a workflow automation server.
The Real Cost of Skipping This
Server compromises don't always look dramatic. Sometimes an attacker installs a cryptocurrency miner that quietly uses your CPU. Sometimes they use your server as a relay for spam or attacks against other servers. Sometimes they sit quietly, waiting to exfiltrate data.
The common thread is that you don't notice until the damage is done. Your VPS provider sends you an abuse complaint. Your application slows down inexplicably. Your data shows up somewhere it shouldn't.
Hardening takes 10 minutes with Ansible. Recovery from a compromise takes days — and that's assuming you have backups. If you don't, you're rebuilding from scratch.
Getting Started
If you're comfortable with Ansible, start with the official Ansible documentation and community hardening roles on Ansible Galaxy. There are well-maintained roles for SSH hardening, firewall configuration, and system updates that you can use as a starting point.
If you'd rather have your server hardened professionally — with SSH lockdown, UFW firewall, automatic updates, and Docker containerization included — Deploy Hawk handles the full security stack as part of every deployment. Every server we touch gets the same battle-tested Ansible playbook, whether it's running a password manager, workflow automation, or AI assistant.
Your server is either hardened or it's a target. There's no middle ground.