Niche: vps
A secure VPS is defined not by its hardware specs but by the rigor of its configuration management. This guide provides a practical framework for managing credentials, detecting leaked secrets in codebases, and hardening access controls.
We often judge server security by looking at the wrong metrics. A VPS with 64GB of RAM and NVMe storage feels robust, but it doesn’t stop a SQL injection attack any more than a bicycle does. The true strength of your virtual private server lies in its soft layer: how you manage SSH keys, where you hide your API tokens, and whether your environment variables are exposed to the public.
For sysadmins and indie hackers managing their own infrastructure, security is rarely about buying better hardware. It is about discipline. This checklist focuses on that discipline. We will move past basic firewall rules to look at the granular details of configuration management, using tools like Gitleaks to catch secrets before they become liabilities.
Why Configuration Beats Hardware for VPS Security
The illusion of security is a common trap in the hosting world. We assume that because our provider offers DDoS protection and enterprise-grade CPUs, our server is safe from within. But powerful processors do not stop brute-force SSH attacks, nor do they prevent a developer from accidentally committing a database password to a public repository.
Understanding the shared responsibility model is critical here. Your hosting provider secures the hypervisor, the physical network, and the underlying infrastructure. They ensure your VPS stays online and connected. You, however, are responsible for securing the guest operating system and everything running inside it. If you leave port 22 open to the world with password authentication enabled, no amount of hardware power will save you from a relentless botnet.
This shift in perspective changes how we define security scope. It is no longer just about firewalls. It includes:
- Secrets Management: Where are your API keys, tokens, and passwords stored?
- Key Rotation: How often do you update access credentials?
- Environment Variables: Are they injected cleanly into services or hardcoded in files?
When you treat configuration as a primary security layer, you reduce your attack surface significantly. A misconfigured server with 2GB of RAM is far more vulnerable than a well-tuned server with 16GB.
SSH Key Management: The First Line of Defense
For most VPS users, SSH (Secure Shell) is the front door. If someone gets in through SSH, they are usually inside the house. Therefore, how you manage your SSH keys dictates the baseline security posture of your server.
Disable Password Authentication
The simplest step with the highest impact is disabling password authentication. Brute-force attacks rely on guessing passwords. By setting PasswordAuthentication no in your /etc/ssh/sshd_config, you eliminate this vector entirely. Without a password, an attacker needs the specific private key to log in.
Use Ed25519 Keys Over RSA
Not all keys are created equal. While RSA is widely supported, it requires larger key sizes (4096 bits) to remain secure against modern computing power. Ed25519 keys offer equivalent security with much smaller sizes and faster performance. They are less prone to timing attacks and generate more quickly. Unless you have legacy systems that require RSA, Ed25519 is the standard for new VPS deployments.
Implement Key Rotation
Keys expire. This is not just a policy; it is a practice. If an employee leaves or a laptop is stolen, their key should no longer grant access. Implementing a rotation policy ensures that old keys are removed from the ~/.ssh/authorized_keys file regularly. Restrict access by specifying which users can connect via specific keys.
The best security is invisibility. If an attacker cannot guess your password and doesn’t have your key, they see only a closed door.
Detecting Leaked Secrets with Gitleaks
One of the most common causes of VPS breaches is hardcoded secrets in application code. A developer might push a .env file or a configuration script containing an AWS access key to a Git repository. If that repo is public, anyone can download your credentials.
What Is Gitleaks?
Gitleaks is a Go-based open-source tool designed to find secrets in git repositories. It scans code for patterns that match API keys, tokens, passwords, and other sensitive data. With over 28,000 stars on GitHub, it has become a standard tool in the DevOps toolkit.
Why It Matters for VPS
Your VPS hosts your application code, often in directories like /var/www or /opt. If that directory is part of a version control system, Gitleaks can scan it to ensure no secrets are committed. This prevents sensitive data from leaking into history.
Integration Tips
Don’t rely on manual scans. Integrate Gitleaks into your CI/CD pipeline. Run the scan before deployment to the VPS. If a secret is detected, the build fails or raises an alert. This catches leaks early, when they are easiest to fix.
- Local Scans: Run
gitleaks detect --source .in your project directory before committing. - Pipeline Checks: Add a step in GitHub Actions or GitLab CI to run Gitleaks on every push.
- Custom Rules: Define custom patterns for proprietary secrets specific to your stack.
Hardening Environment Variables and Config Files
Beyond code, the server itself holds configuration files. These files often contain database passwords, SMTP credentials, and API keys. How you protect these files on disk matters.
The Danger of .env Files
Environment variables are convenient, but .env files are often left in production directories with default permissions (644). This means any user on the system can read them. In a shared hosting environment or if another service runs under a different user, your secrets are exposed.
Permissions Best Practices
Set restrictive permissions for sensitive config files. Using chmod 600 ensures that only the owner can read and write the file. For scripts that execute as root, consider using chmod 700.
- Regular Files:
chmod 600 config.yml - Executable Scripts:
chmod 700 deploy.sh - Directories:
chmod 750 /var/www/configto prevent listing contents.
Dedicated Secret Managers
For dynamic secrets, consider using a dedicated secret manager like HashiCorp Vault. It allows you to rotate credentials without restarting services. Systemd drop-ins can also inject secrets directly into service files, keeping them out of plain-text config files entirely.
Network Security Beyond the Firewall
Your VPS provider’s firewall is a good start, but it is not enough. You need host-level controls to filter traffic arriving at your server.
Closing Unused Ports
Every open port is a potential entry point. Regularly audit which ports are listening using ss -tulnp. Close any that are not in use. For example, if you are not running MySQL on the VPS, close port 3306.
Configuring Fail2ban
Fail2ban scans log files for failed login attempts and bans the offending IP address after a threshold is reached. It is essential for protecting SSH and web services from brute-force attacks. Configure it to monitor /var/log/auth.log and block IPs that fail more than five times in ten minutes.
Using Reverse Proxies
Hide your backend services behind a reverse proxy like Nginx or Apache. The proxy handles SSL termination and forwards requests to your application on localhost. This way, only port 443 (HTTPS) needs to be open to the world, not ports for every individual service.
- SSL Termination: Offload TLS processing from your app server.
- IP Hiding: Backend services listen on 127.0.0.1 only.
- Load Balancing: Distribute traffic across multiple backend processes.
Automating Security with Infrastructure as Code
Human error is the largest threat to VPS security. Typing chmod 777 instead of 600 happens. Infrastructure as Code (IaC) reduces this risk by enforcing consistent configurations.
Using Ansible or Terraform
Tools like Ansible allow you to define your server’s state in code. You can specify that SSH keys must be Ed25519, that fail2ban is installed, and that config files have 600 permissions. When you run the playbook, the server is brought into compliance automatically.
Version Controlling Your Config
Treat your infrastructure like application code. Store your Ansible playbooks or Terraform scripts in a Git repository. This allows you to review changes via pull requests and roll back if a configuration breaks security.
Auditing Changes
Keep a history of who changed what and when. This is invaluable for debugging breaches. If a secret appears in your logs, you can check the Git history to see which commit introduced it.
- Consistency: Every new server matches the last one.
- Traceability: Changes are tracked and reviewable.
- Speed: Deploy security patches to all servers simultaneously.
Conclusion: Building a Security-First VPS Workflow
A secure VPS is not built in a day. It is the result of continuous, small improvements. By focusing on configuration management, you address the most common sources of breaches.
Recap the three pillars:
- SSH Keys: Disable passwords, use Ed25519, and rotate keys.
- Secret Detection: Use Gitleaks to find hardcoded secrets in your codebase.
- Config Hygiene: Set strict permissions on config files and manage environment variables carefully.
Start small. Pick one area from this checklist—perhaps disabling root login or scanning for leaked keys—and improve it today. Security is a process, not a product. By embedding these practices into your workflow, you build a defense that grows stronger with every deployment.
Frequently Asked Questions
Is Gitleaks fast enough for large repositories?
Gitleaks is written in Go and is optimized for speed. It can scan thousands of commits in seconds, making it suitable for both small personal projects and large enterprise codebases.
Can I use the same SSH key on multiple VPS instances?
Yes, but it is best practice to generate unique keys per server or per user. This allows you to revoke access to a specific server without affecting others.
How often should I rotate my API keys?
Rotate critical keys (like AWS or Stripe) every 90 days. Less sensitive keys can be rotated annually, but always immediately if they are exposed.
Practical Checklist
- Disable SSH password authentication
- Generate Ed25519 SSH keys
- Install and configure Gitleaks in CI/CD
- Set chmod 600 on all config files
- Enable fail2ban for SSH and web services
- Close unused ports in the host firewall
- Use a reverse proxy for SSL termination
- Version control your server configuration (Ansible/Terraform)