10 Common VPS Configuration Mistakes (and How to Avoid Them)

VPS configuration mistakes can turn a powerful server into an open door for attackers or a constant source of downtime. Most serious VPS problems are preventable and repeat themselves over and over among users who are new to managing their own server.

This guide covers the ten most common mistakes, explains why they are dangerous, and provides the exact fix for each one. Whether you are setting up your first VPS or auditing one already in production, here is the checklist you need.

1. Leaving Root SSH Access Enabled

The most common and dangerous mistake: allowing the root user to log in directly via SSH. Brute-force bots continuously scan the internet attempting root credentials.

Fix: Create a user with sudo privileges, disable root login in /etc/ssh/sshd_config (PermitRootLogin no), and restart the SSH service.

adduser adminuser
usermod -aG sudo adminuser
# In /etc/ssh/sshd_config:
PermitRootLogin no

2. Not Changing the Default SSH Port

Port 22 is the first port attackers scan. Not changing it is not critical on its own, but it dramatically amplifies the attack surface when combined with weak passwords.

Fix: Change the port to a high number (for example, 2299) in /etc/ssh/sshd_config. Remember to open the new port in the firewall before closing your current session.

3. Not Setting Up a Firewall from the Start

A freshly installed VPS typically has all ports open. Without a firewall, any service you install is immediately exposed to the internet.

Fix: Enable ufw or iptables right after the OS installation, before installing anything else. Allow only the ports you actually need.

ufw allow 2299/tcp   # your custom SSH port
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Browse more server hardening articles in our VPS servers category.

4. Using Weak Passwords or Skipping SSH Keys

Short or predictable passwords are cracked by dictionary attacks in minutes. Many providers send the root password by email; changing it immediately is mandatory.

Fix: Use SSH public-key authentication and disable password authentication on the server.

# In /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes

5. Not Keeping the System Updated

Kernel and system-package vulnerabilities are published constantly. An unpatched server accumulates known attack vectors that are trivial for automated tools to exploit.

Fix: Apply security updates regularly. On Debian/Ubuntu you can automate critical patches:

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

On CentOS/AlmaLinux/Rocky Linux, use dnf-automatic for the same effect.

6. Forgetting Automatic Backups

Many administrators assume the provider backs up the server. On an unmanaged VPS, backups are the customer's responsibility. A single disk failure or ransomware attack without a backup can cost days of work.

Fix: Set up automatic backups from day one. This can be a daily provider snapshot, an rsync script to external storage, or both. Verify that backups can actually be restored.

7. Not Monitoring Resources or Logs

Without monitoring, a runaway process can consume all RAM or disk space and bring the server down hours before the administrator notices. Logs are the first clue when something goes wrong.

Fix: Install a minimal monitoring tool (Netdata, Prometheus + Grafana, or even provider alerts). Review /var/log/syslog, /var/log/auth.log, and application logs regularly.

8. Not Separating Environments (Production, Staging, Development)

Making changes directly in production without prior testing is a recipe for unexpected downtime. One mistake in a code or configuration update can take down your site in seconds.

Fix: Maintain at least a staging environment, even if it is on the same VPS as a separate virtual host. Test there before deploying to production.

9. Exposing Database Services to the Internet

MySQL, PostgreSQL, and MongoDB should not be listening on a public interface. When they are, they are exposed to automated scans and direct injection attacks.

Fix: Configure the database to listen only on 127.0.0.1 (localhost). If you need remote access, do it through an SSH tunnel, never by opening the port in the firewall.

# In /etc/mysql/mysql.conf.d/mysqld.cnf:
bind-address = 127.0.0.1

10. Ignoring File and Directory Permissions

Overly permissive permissions (777 on web files, for example) allow any server process to read or modify files it should not touch. This is a common vector for privilege escalation.

Fix: Web files should belong to the web server user or application user, with 644 permissions for files and 755 for directories. Never use 777 in production.

find /var/www/myapp -type f -exec chmod 644 {} \;
find /var/www/myapp -type d -exec chmod 755 {} \;

Key Takeaways

• Disable root SSH login from the very start and use public-key authentication.
• Enable the firewall before installing any service.
• Set up automatic backups and verify they actually work.
• Keep the system updated with security patches.
• Never expose databases or internal services to the internet.
• Monitor resources and review logs regularly.
• Separate environments: never deploy directly to production without testing first.
• Apply correct file permissions; never use 777 in production.

If you want expert help avoiding all of these mistakes on your next server, the team at elenlace.com offers VPS setup and hardening services tailored to your needs.

FAQ

What is the most serious VPS configuration mistake?

Leaving root SSH access enabled with password authentication is by far the most dangerous mistake. Automated bots exploit it within hours of a server going online.

How often should I back up my VPS?

At a minimum, once a day for critical data. For e-commerce databases or transactional applications, consider hourly backups or more frequent ones, with a retention period of at least 7 days.

Do I need monitoring for a small VPS?

Yes. Even a 1 GB RAM VPS can be saturated by a misconfigured process or a minor DDoS attack. Basic monitoring is free (Netdata Community) and can alert you before the problem affects your users.

Is changing the SSH port mandatory?

Not mandatory, but it dramatically reduces bot noise in your logs and the automated attack surface. The most important steps are disabling password authentication and root login; changing the port is an additional layer of defense in depth.

Prefer it done for you? El Enlace handles hosting and professional web development.

Compare providers

Other providers and guides worth comparing:

• HostGator México
• Hostinger
• HubSpot