VPS Security Checklist: 10 Steps to Secure Your Server

Getting a new VPS is exciting. You have root access, a blank operating system, and the freedom to build anything. But that same freedom makes your server a target. Within hours of going live, bots scan your IP for open ports, try common passwords, and probe for vulnerabilities.

Securing your VPS is not optional. It is the foundation of running any production service. The good news is that a properly secured server is not that hard to achieve. Most attacks are opportunistic. They target easy wins. If you make your server harder to break into than the next one, the bots move on.

This checklist covers the ten most important steps to secure your Linux VPS. Follow these in order, and your server will be well protected against the vast majority of common attacks.

Why Server Security Matters

Before we get into the steps, let us be clear about what we are protecting against.

Automated attacks are constant. Bots scan the entire internet looking for servers with open SSH ports, weak passwords, and known vulnerabilities. They try thousands of combinations per minute. If your SSH password is anything less than a strong random string, it will be compromised eventually.

Lack of updates is the most common vulnerability. Old software has known exploits. Attackers do not need to be sophisticated. They just scan for servers running versions with published CVEs.

Misconfiguration creates openings. A firewall rule that is too permissive, a service that exposes an admin panel to the public internet, or a database that accepts connections from anywhere are all invitations.

Insider threats exist within your own tools. Granting your AI agent root access without limits, storing API keys in world-readable files, or leaving debug endpoints enabled are risks you create yourself.

A server that follows this checklist closes all of these attack vectors.

Step 1: Update Everything Immediately

The first thing you should do on a fresh VPS is update all system packages. The operating system image your provider gave you may be months old, and those months contain discovered and patched vulnerabilities.

sudo apt update && sudo apt upgrade -y

This updates all installed packages to their latest versions. For CentOS or Fedora, use yum update or dnf upgrade.

After the update, check if a reboot is needed. Kernel updates require a reboot to take effect.

# Check if reboot is needed
sudo reboot-required

If the file exists, reboot your server. This ensures you are running the latest kernel with all security patches applied.

Configure automatic security updates so you do not have to remember to do this manually.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

This installs and configures automatic security updates. Critical patches get applied within hours of release.

Step 2: Create a Non-Root User and Disable Root Login

Root is the most powerful account on your Linux system. It can do anything. That is exactly why you should not use it for daily work. One wrong command as root can destroy your entire server.

Create a regular user with sudo privileges.

sudo adduser yourusername
sudo usermod -aG sudo yourusername

Test that the new user can run sudo commands. Then disable root login over SSH.

Edit /etc/ssh/sshd_config and set:

PermitRootLogin no

Restart SSH for the change to take effect.

sudo systemctl restart sshd

From this point forward, always SSH in as your regular user and use sudo for administrative tasks. If an attacker somehow gets your user password, they still need to escalate to root through a separate vulnerability.

Step 3: Use SSH Key Authentication Instead of Passwords

Password-based SSH authentication is the single most attacked vector on any public server. Bots try millions of passwords against open SSH servers. Even a strong password is vulnerable if SSH brute force attacks run long enough.

SSH key authentication is cryptographically secure. A private key is essentially impossible to brute force. Switch to keys and disable password authentication.

Generate a key pair on your local machine.

ssh-keygen -t ed25519 -a 100

Copy the public key to your server.

ssh-copy-id yourusername@your-server-ip

Once the key is installed and working, disable password authentication. Edit /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Restart SSH.

sudo systemctl restart sshd

Now only users with the corresponding private key can SSH into your server. Bots can try passwords all day and they will never succeed.

Step 4: Change the Default SSH Port

SSH runs on port 22 by default. Every bot in the world knows this. They scan for port 22 and immediately start brute force attempts. Changing the port stops 99 percent of automated attacks immediately.

Choose a port between 1024 and 65535 that is not already in use by another service. Edit /etc/ssh/sshd_config:

Port 2222

Replace 2222 with your chosen port number. Make sure to update your firewall rules to allow the new port and remove the old one.

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp

Restart SSH and test the connection on the new port before closing your current session.

ssh -p 2222 yourusername@your-server-ip

Once you confirm the new port works, you are safe to close your old session. From now on, you authenticate on a non-standard port that automated scanners largely ignore.

Step 5: Set Up a Firewall

A firewall restricts what network traffic can reach your server. Only the ports you explicitly open are accessible. Everything else is blocked.

UFW (Uncomplicated Firewall) is the simplest way to manage iptables on Ubuntu.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp   # Your custom SSH port
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS
sudo ufw enable

Only the ports you list are open. Everything else is blocked. If you run additional services like databases or custom applications, add rules for those specific ports.

For CentOS or Fedora, use firewalld instead.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

After your firewall is active, you can scan your own server to confirm only the intended ports are open.

sudo nmap localhost

If you see anything unexpected, investigate and close it.

Step 6: Install and Configure Fail2ban

Fail2ban monitors log files for repeated failed authentication attempts. When it detects someone trying and failing to log in too many times, it temporarily bans their IP address using the firewall.

sudo apt install fail2ban

Copy the default configuration and customize it.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

The default settings are reasonable for most servers. Fail2ban watches SSH logs by default. If you changed your SSH port, make sure the jail matches.

[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600

This bans any IP that fails SSH authentication five times within a ten-minute window. The ban lasts for one hour. Restart Fail2ban to apply changes.

sudo systemctl restart fail2ban

You can check the current ban status with:

sudo fail2ban-client status sshd

Fail2ban is one of the most effective defenses against automated attacks. Combined with key-based SSH authentication, your server becomes extremely difficult to compromise through SSH.

Step 7: Secure Shared Memory

Linux shared memory (/dev/shm) is a world-writable memory space that processes use for interprocess communication. It is also a common vector for privilege escalation and malware execution.

You can secure it by remounting it with restricted permissions. Edit /etc/fstab and add:

tmpfs /dev/shm tmpfs defaults,nosuid,noexec,nodev 0 0

This prevents any process from executing code from shared memory. Apply the change:

sudo mount -o remount /dev/shm

This is a simple step that closes a known attack vector used by many exploits.

Step 8: Enable Automatic Security Updates

We covered this briefly in Step 1, but it deserves its own spot on the checklist. Security updates are released continuously. The window between a patch being published and attackers exploiting the vulnerability is shrinking. Automatic updates ensure you are patched within hours, not whenever you remember to check.

For Ubuntu:

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

Configure what gets updated automatically. The safest option is to apply all security updates automatically.

For CentOS/RHEL:

sudo yum install yum-cron
sudo systemctl enable yum-cron
sudo systemctl start yum-cron

Automatic updates are your safety net. Even if you forget to check for updates for months, your server stays protected against known vulnerabilities.

Step 9: Audit Open Ports and Running Services

Every open port and running service is a potential attack surface. The fewer services you run, the fewer things can go wrong.

List all open ports on your server.

sudo ss -tulpn

This shows every service listening on a TCP or UDP port. For each one, ask yourself: do I really need this service? If a service is listening on a public interface and you do not use it externally, bind it to localhost.

Check your firewall rules to confirm only the intended ports are open to the public.

sudo ufw status verbose

For each unnecessary open port, either configure the service to listen only on localhost, remove the package entirely, or add a firewall rule to block external access.

This is also a good time to check what services are enabled at boot.

sudo systemctl list-unit-files --type=service --state=enabled

Disable any services you do not need at startup.

sudo systemctl disable servicename

Every disabled service is one less thing that can be exploited.

Step 10: Secure Your AI Agent and Application Credentials

If you use an AI agent to manage your VPS, securing agent access is as important as securing your own SSH access. An agent with full root access and no restrictions is a powerful tool, but also a powerful risk if something goes wrong.

Create a dedicated user for your AI agent with limited permissions.

sudo adduser ai-agent
sudo usermod -aG sudo ai-agent

Then use sudoers configuration to restrict what the agent can do with elevated privileges.

sudo visudo -f /etc/sudoers.d/ai-agent

Add specific command restrictions.

ai-agent ALL=(ALL) NOPASSWD: /usr/bin/systemctl *, /usr/bin/apt *, /usr/bin/journalctl *

This gives the agent permission to manage services, install packages, and check logs without granting unrestricted root access. You can add or remove commands based on what your agent needs.

Store API keys, database passwords, and other secrets as environment variables or use a secrets manager. Never hardcode them in agent prompts, configuration files, or scripts.

# Set secrets in environment
export OPENAI_API_KEY="sk-your-key-here"
export DB_PASSWORD="your-database-password"

# Or use a .env file
echo "OPENAI_API_KEY=sk-your-key-here" >> /etc/ai-agent/.env

Restrict file permissions on any files containing secrets.

sudo chmod 600 /etc/ai-agent/.env
sudo chown ai-agent:ai-agent /etc/ai-agent/.env

Bonus: Regular Security Audits with Your AI Agent

After you have completed the checklist, ongoing maintenance matters. Security is not a one-time setup. It requires regular attention.

Your AI agent can help here. Ask it to audit your server security on a schedule. It can check that SSH key authentication is still enabled, that the firewall is active, that Fail2ban is running, that there are no unexpected open ports, and that security updates were applied.

A weekly security summary from your AI agent lets you stay on top of vulnerabilities without manual checks. If something changes, the agent flags it immediately. If everything is fine, you get a quick confirmation and move on.

Frequently Asked Questions

Q: Do I really need to change the SSH port?

It is one of the most effective single changes you can make. Bots scan for port 22 specifically. Changing the port eliminates almost all automated brute force attempts. Combined with key-based authentication, your SSH server becomes practically invisible to automated attacks.

Q: Can Fail2ban ban legitimate users?

It can if they mistype their password multiple times. The bans are temporary (one hour by default). If a legitimate user gets banned, they wait an hour or you can manually unban their IP.

sudo fail2ban-client set sshd unbanip 1.2.3.4

Q: Is UFW enough for a production server?

UFW is sufficient for most use cases. It manages the underlying iptables rules that are the standard Linux firewall. For advanced scenarios with complex routing, multiple network interfaces, or VPN integration, you may need direct iptables or nftables configuration.

Q: How often should I review my server security?

Monthly is a good baseline. Quarterly is the minimum. Your AI agent can automate weekly checks and alert you to any changes, making the manual review quicker when you do it.

Q: What is the most important security step?

Updating your system and disabling password-based SSH authentication are the two most impactful steps. Everything else builds on this foundation.

Build a Secure Foundation

A secure VPS is not complicated. It is a series of straightforward steps that combine to create layered defense. Each step closes specific attack vectors. Together, they make your server a hard target.

At AgentVPS, security is built into our platform. Your VPS comes preconfigured with best practices, and your AI agent helps you stay on top of maintenance. You get the security of a well-hardened server without spending your time managing it.

Contact us on WhatsApp to learn how AgentVPS handles server security so you can focus on building.