> ## Content Index > Fetch the complete content index at: https://corelab.tech/llms.txt > Use this file to discover other available public pages before exploring further. # The 2026 VPS Security Checklist: Hardening Debian & Ubuntu Servers - URL: https://corelab.tech/vps-security-hardening/ - Published: 2025-11-18T16:36:50.000Z - Updated: 2026-10-31T16:06:37.000Z - Description: The first 10 minutes after spinning up a VPS matter most. A 2026 hardening checklist for both managed (cPanel/WHM) and unmanaged (root/SSH) Debian and Ubuntu servers. - Author: Core Lab Joe - Tags: VPS, Cybersecurity, Linux, #2025, #table-of-content > What to do right now to secure your server, with specific guides for Managed (GreenGeeks) and Unmanaged (HostPapa) plans. ## **🚀 The Clock is Ticking** You just spun up a brand new, blazing-fast Virtual Private Server (VPS). That public IP address is aaalllll yours. It’s an exciting moment, but it’s also a critical one. From the instant your VPS goes online, it's exposed to the public internet and automated bots are *already* scanning it for weaknesses. Sadly this has been the state of the internet for many years by this point and is just the facts of reality online. Your first 10 minutes are not just important; they are *the* most important 10 minutes of your server's life. But here’s the most critical piece of advice you’ll get: **What you do in these 10 minutes depends entirely on what kind of VPS you bought.** A "Managed" VPS is not the same as an "Unmanaged" VPS, and running a security checklist for one or the other can be useless at best and destructive at worst. - **Unmanaged VPS:** (e.g., Web Hosting Canada, DigitalOcean, Vultr, or HostPapa's "Unmanaged" tier). This is a blank slate. You get an operating system (like Ubuntu or AlmaLinux), a public IP, and `root` access. You are the system administrator. You are 100% responsible for all security. - **Managed VPS:** (e.g., Web Hosting Canada, GreenGeeks or HostPapa's "Managed" **tier**). This is a "service" model. Your server comes pre-configured, hardened, and (most importantly) with a control panel like **cPanel/WHM**. The host manages core security, updates, and the firewall. *You are the account administrator*, not the sysadmin. Big difference here! > This guide will give you the *correct* 10-minute checklist for both scenarios, so you can lock down your new server the right way. I evaluate and benchmark reliable VPS providers in my lab. For an in-depth performance breakdown, read [my best web hosting and cloud server value guide](https://corelab.tech/best-black-friday-hosting-value-2025/): [![Web Hosting Canada](https://s.whc.ca/affiliates/banners/green-hosting-leaderboard.png)](https://whc.ca/canadian-web-hosting?aff=7875&ref=corelab.tech) ![HostPapa VPS](https://media.go2speed.org/brand/files/opienetwork/439/20230519095301-Affiliate-Banner_EN_Static_728x90.png) ### HostPapa VPS [Sign up!](https://tracking.opienetwork.com/aff%5Fc?offer%5Fid=439&aff%5Fid=24925&url%5Fid=425&file%5Fid=6572&ref=corelab.tech) [![](https://ads.greengeeks.com/00030043.gif)](https://www.greengeeks.com/track/corelabjoe/cp-default?ref=corelab.tech) --- ### **Managed vs. Unmanaged VPS: Which is Right for You?** Here is a side-by-side comparison to help you understand the fundamental differences between the two hosting models. | Feature | Managed VPS | Unmanaged VPS | | --------------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | **Server Management** | The hosting provider handles all server maintenance, updates, and patches. | **You** are 100% responsible for all server management tasks. | | **Technical Expertise** | **Beginner-friendly.** No command-line or server admin skills needed. | **Expert-level.** Requires strong knowledge of Linux, security, and networking. | | **Support** | **Comprehensive 24/7 support** for all server-related issues, including setup, security, and troubleshooting. | **Basic support** for hardware and network issues only. You fix your own software problems. | | **Control & Customization** | Less flexible. You have limited control and can only use what the provider supports. | **Full root access.** Complete control to install any OS, software, or custom configuration. | | **Security** | **Proactive security** managed by the provider (firewalls, patching, malware scans). | **DIY security.** You are solely responsible for setting up firewalls, applying patches, and monitoring. | | **Software Installation** | Handled by the provider or through a control panel (like cPanel or Plesk). | You must manually install and configure all software (web server, database, etc.). | | **Backups** | Usually included and automated by the provider. | You must set up and manage your own backup solution. | | **Cost** | **Higher.** You are paying for the server *and* the expert management service. | **Lower.** You are only paying for the server resources. | | **Best For...** | Business owners, bloggers, and non-technical users who value convenience and support. | Developers, system administrators, and tech-savvy users who need full control. | --- ## **🛡️ Section 1: The "Unmanaged" VPS Checklist (The Sysadmin's 10 Minutes)** This checklist is for you if you have a "blank" server and `root` command-line access. This applies directly to HostPapa's Unmanaged VPS plans. **Your Goals:** 1. Create a secure non-root user 2. Disable password logins and; 3. Set up a basic firewall. (UFW is great) We'll use Ubuntu/Debian commands as the example, with notes for AlmaLinux/RHEL. ### Step 1: Log in as Root (For the Last Time) Your provider gave you a `root` password or a pre-loaded SSH key. Use it to log in. ```bash ssh root@YOUR_SERVER_IP ``` You are now the super-user. Never use this account for daily work. ### Step 2: Create Your Day-to-Day User We'll create a new user and give it `sudo` (administrator) privileges. I'll use `corelab` as the username, **but you should use your own.** ```bash # Creates the user and their home directory adduser corelab # Add the user to the 'sudo' group (for Ubuntu/Debian) usermod -aG sudo corelab # (For AlmaLinux/RHEL users, use the 'wheel' group instead) # usermod -aG wheel corelab ``` ### Step 3: Set Up SSH Key Authentication (The 'VIP Pass') Passwords can be guessed or brute-forced. SSH keys are nearly impossible to crack. We will copy your local *public* SSH key to the new user. The steps below will get you there, but to customize/specify SSH key generation, [check this guide out](https://diymediaserver.com/post/complete-guide-securing-ssh-server/?ref=corelab.tech). First, from your **local computer**, copy your public key. If you don't have one, search for `ssh-keygen`. ```bash # This command appends your local public key to the user's 'authorized_keys' file on the server ssh-copy-id corelab@YOUR_SERVER_IP ``` If `ssh-copy-id` isn't available, do it manually. Log back in as `root` and run: ```bash # As root, create the .ssh directory for your new user mkdir -p /home/corelab/.ssh # Open the authorized_keys file with a text editor nano /home/corelab/.ssh/authorized_keys ``` Now, **paste your *public* key** (the contents of your `id_rsa.pub` file) into the editor, save, and exit. Finally, set the correct permissions: ```bash chown -R corelab:corelab /home/corelab/.ssh chmod 700 /home/corelab/.ssh chmod 600 /home/corelab/.ssh/authorized_keys ``` ### Step 4: Harden the SSH Server (Locking the Front Door) Now we'll tell the server to *only* accept key-based logins and to *refuse* any `root` login attempts. ```bash # Open the SSH configuration file nano /etc/ssh/sshd_config ``` Find and change these three lines. Remove the `#` at the beginning if they are commented out: ```bash # Change default port from 22 to something else higher, like 2222 or even 20025 Port 22 <- Default bad Port 2025 <- Better! # Change this from 'yes' to 'no' PermitRootLogin no # Make sure this is 'yes' PubkeyAuthentication yes # Change this from 'yes' to 'no' (This disables password logins) PasswordAuthentication no ``` Save the file and exit. ### Step 5: Test and Restart SSH **This is the most critical step.** Before you log out, you *must* test your new setup. **Open a NEW terminal window** on your local computer and try to log in as your *new user* on your new port that you set above. ```bash ssh corelab@YOUR_SERVER_IP ``` It should log you in *without* asking for a password. If it works, you can safely `exit` your `root` session. **Restart the SSH service:** ```bash systemctl restart sshd ``` **Test the config file:** ```bash sshd -t # If it returns no errors, you're good. Restart SSH and now use your new port! systemctl restart ssh ``` ### Step 6: Configure the Firewall (The 'Bouncer') We'll use UFW (Uncomplicated Firewall) on Ubuntu. ```bash # Logged in as your new 'corelab' user sudo ufw allow 2025/tcp # IMPORTANT: This allows your SSH connection! sudo ufw enable # This turns the firewall on sudo ufw status # This shows you the active rules ``` For AlmaLinux/RHEL, `firewalld` is the default: ```bash # sudo firewall-cmd --add-service=ssh --permanent # sudo firewall-cmd --reload ``` ### Step 7: Install & Configure Fail2Ban ```bash apt install fail2ban ``` It's best practice to copy the default configuration file to a local version so that future Fail2Ban package updates don't overwrite your changes. ```bash sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local ``` You need to edit the new `jail.local` file and modify the settings for the `[sshd]` jail. ```bash sudo nano /etc/fail2ban/jail.local ``` - Find the `[sshd]` section (it may be far down in the file). - Ensure the jail is **enabled** and explicitly set the **port** to your custom port, **2025**. ```bash [sshd] enabled = true port = 2025 filter = sshd logpath = %(sshd_log)s maxretry = 3 bantime = 1h # action is typically set in the [DEFAULT] section to use ufw, # but if you need to override, you can specify 'action = ufw' here. ``` **`enabled = true`**: Activates this specific protection rule. - **`port = 2025`**: This is the most critical change. It tells Fail2Ban to check the log file for failed attempts on this specific port and, more importantly, tells the **UFW action** to block the IP on this port. - **`maxretry = 3`**: The number of failures allowed before a ban. - **`bantime = 1h`**: The duration (in this example, 1 hour) for which the IP will be banned. Finally, set the banaction in defaults to = ufw ```bash # # MISCELLANEOUS OPTIONS # [DEFAULT] # ... other settings like bantime, findtime, maxretry banaction = ufw ``` `sudo systemctl restart fail2ban` **Check UFW/Fail2Ban logs:** - Check the Fail2Ban log for the ban action: `sudo tail -f /var/log/fail2ban.log` - Check your active UFW rules after the ban occurs: `sudo ufw status numbered` (You should see a new `REJECT` or `DENY` rule against the attacking IP address on port 2025). ### Step 8: Update Everything Finally, apply all security patches. ```bash # For Ubuntu/Debian sudo apt update && sudo apt upgrade -y # For AlmaLinux/RHEL # sudo dnf upgrade -y ``` **Done!** Your server is now hardened and ready. --- ## 🎛️ Section 2: The "Managed" VPS Checklist (The Admin's 10 Minutes) This checklist is for you if your VPS came with a control panel like **cPanel/WHM**. This applies directly to GreenGeeks Managed VPS and HostPapa's Managed VPS plans. **DO NOT** follow the unmanaged guide. You will fight with your provider's configuration and may break your server. **Your Goal:** Secure your *billing and admin accounts* and let the host manage the server's core. It's a little simpler, but you pay for that as well. ### Step 1: Secure Your Billing Account (The 'Home Base') Your "First 10 Minutes" start in your *provider's* dashboard (the HostPapa or GreenGeeks client area). This account controls your billing and server. If an attacker gets in here, ***it's game over.*** - **Action:** Find the "Security" or "Account" settings and **enable Two-Factor Authentication (2FA)**. Do this before you even look at your server. Do it now / immediately. For reals, it's that important. ### Step 2: Log in to WHM (The 'Server Control Room') Your provider's welcome email or dashboard will contain a link to your **WebHost Manager (WHM)**. The URL is typically `https://YOUR_SERVER_IP:2087`. - You will log in as the `root` user with the password provided. This is *not* the same as `root` SSH. This is the `root` *admin for the control panel*. ### Step 3: Change the Root WHM Password Your first action inside WHM should be to change the password you were given. - **Action:** In WHM, go to **"Server Configuration" > "Change Root Password"**. Use a strong, unique password (or a password manager) and save it. ### Step 4: Enable Two-Factor Authentication (2FA) in WHM Just like your billing account, your WHM admin account needs 2FA. - **Action:** In WHM, go to **"Security Center" > "Two-Factor Authentication"**. Enable it and configure it with your preferred authenticator app. ### Step 5: Review Built-in Security Tools A managed server *already has a firewall and security suite*. Your job is to check that they're on, not install your own. - **Action:** In WHM, go to **"Security Center"** and review: - **cPHulk Brute Force Protection:** Ensure this is enabled. It protects your login pages (cPanel, WHM, SSH) from password-guessing attacks. - **Security Advisor:** Run the built-in scanner. It will flag any simple security misconfigurations. **GreenGeeks** specifically provisions **AlmaLinux 8** and includes custom security rules and monitoring. Trust that they are handling the base firewall. ### Step 6: Create Your First cPanel Account Your final step is to *stop* using the `root` WHM account. You use WHM to *manage* the server, but you use **cPanel** to *host your websites*. - **Action:** In WHM, go to **"Account Functions" > "Create a New Account"**. Fill in the details for your blog (`corelab.tech`). This creates a new, sandboxed cPanel user. From now on, you will log in to *that* cPanel account to manage your site's files, databases, and email. --- ## 🏁 Conclusion: Know Thy Server As you can see, the "first 10 minutes" are dramatically different depending on your provider. - **Unmanaged (HostPapa Unmanaged):** You are the sysadmin. Your job is to harden the operating system from the command line. - **Managed (GreenGeeks, HostPapa Managed):** You are the admin. Your job is to harden your *accounts* (Billing and WHM) with 2FA and let the host's pre-configured tools do their job. Knowing *what* you bought is the most important security step of all. Now that you're locked down, you can get to the fun part: **building**! --- ## ❓ Frequently Asked Questions (FAQ) ### What's the difference between a managed and unmanaged VPS? An unmanaged VPS gives you root access and full responsibility for security, updates, and firewall configuration yourself. A managed VPS comes pre-configured with a control panel like cPanel/WHM, and the host handles core server security and patching, leaving you responsible mainly for your account and admin logins. ### Should I disable root SSH login on my VPS? Yes, on an unmanaged VPS. After creating a non-root user with sudo privileges and setting up SSH key authentication, set `PermitRootLogin` to `no` in `/etc/ssh/sshd_config` so root can never log in directly over SSH. ### Why should I change the default SSH port from 22? Port 22 is the first port every automated bot scans. Moving to a custom high port doesn't add real cryptographic security, but it dramatically cuts down the noise of automated brute-force attempts hitting your logs and Fail2Ban. ### Do I need Fail2Ban if I already have a firewall (UFW)? Yes. A firewall like UFW controls which ports are open, but it doesn't stop repeated login attempts on a port you've deliberately left open for SSH. Fail2Ban watches your logs for failed logins and temporarily bans the offending IP, which a static firewall rule can't do on its own. ### How do I secure a managed VPS with cPanel/WHM? Enable two-factor authentication on both your hosting account/billing dashboard and your WHM root login, change the default WHM root password immediately, and confirm cPHulk Brute Force Protection is active in WHM's Security Center. The host manages the underlying firewall and patching for you. ### Is UFW enough firewall protection for an unmanaged VPS? For a basic single-service VPS, yes, UFW combined with SSH key-only authentication and Fail2Ban covers the fundamentals. It only controls inbound/outbound traffic though, so it doesn't replace other hardening steps like disabling root login or keeping packages updated. [A Practical Cybersecurity Roadmap for HomelabsLearn to protect your data, services and privacy with actionable steps and clear tutorials. So, you’ve built an incredible homelab. You’re spinning up services in Docker, managing your media, and maybe even self-hosting your own website. You are the master of your own data. But with every new service you![](https://corelab.tech/content/images/icon/Glowing_CPU-61.png)Core LabCore Lab Joe![](https://corelab.tech/content/images/thumbnail/ShieldsUp_gud-9.png)](https://corelab.tech/cybersecroadmap/) [The Ultimate Self-Hosted Media Server GuideWe’ve all felt it. You subscribe to three different streaming services, and the one show you want to watch is on a fourth. You’re paying a premium for a fragmented, inconvenient experience. Or maybe you have a vast local library of media, but it’s a mess of folders on a![](https://corelab.tech/content/images/icon/Glowing_CPU-60.png)Core LabCore Lab Joe![](https://corelab.tech/content/images/thumbnail/ksnip_20251020-141430-9.png)](https://corelab.tech/ultimate-media-server-guide/)