Hello and welcome back, friend!

Today in our Architecting Zero Downtime Infrastructure series, we’re tackling something that makes a lot of smart people suddenly get quiet: security.

I see it all the time. Someone spins up a shiny new Proxmox host, starts deploying VMs, and treats security like an optional side quest. But here’s the truth I want you to tattoo on your brain: a compromised system is a downed system. There’s no such thing as “high availability” when someone else is wearing your root account like a winter coat.

So consider today’s episode the non-negotiable foundation work. We’re going to take that fresh Proxmox installation and transform it, step by step, from “wide open Linux server” into a hardened platform you can actually build a business on.

Let’s get to work.

Step 1: Kill the Root Login (Your First Smart Move)

Every attacker on the planet knows the username “root” exists. That’s like putting a giant welcome mat at your front door that says “Key is under the mat.”

My very first action on any new Proxmox node is to create a dedicated administrative user and add it to the sudo group. Once I’ve tested that account, I immediately disable direct root SSH access.

You do this by editing /etc/ssh/sshd_config, finding the line PermitRootLogin, and changing it to:

PermitRootLogin no

One tiny change. Massive impact. Now any attacker needs to guess both a username and a password. We’ve just removed their head start.

Step 2: Isolate Your Management Network (The Front Door)

I like to say the management interface is the front door to your entire virtualization kingdom. In a perfect world, that door sits on its own physical network card, connected to a completely separate switch that nothing else touches.

Not always possible? Fine. But at minimum, that management traffic needs to live on its own dedicated VLAN. No exceptions.

This separation is pure gold. It stops lateral movement cold. If someone compromises a VM, they shouldn’t automatically get a clear path to your hypervisor. Think of it as building a moat.

Step 3: Wake Up the Proxmox Firewall (Most People Sleep on This)

One of my favorite things about Proxmox is that it ships with a perfectly good firewall that most people… completely ignore.

The firewall works at three levels: Datacenter, Host, and VM. For now, we’re focusing on the Host level because we want to protect the hypervisor itself.

Here’s my process:

1. Enable the firewall for the host
2. Set the default input policy to DROP (this is our “deny everything unless I specifically allow it” stance)
3. Create two allow rules: one for the web interface (port 8006) and one for SSH (port 22)
4. Critically, restrict the source to your management workstation’s IP (or a defined IP set)

Suddenly your management ports become invisible to the rest of the world. I love this. It’s simple, fast, and ridiculously effective.

Step 4: Enable Two-Factor Authentication (The Game Changer)

If I could force every Proxmox user to do just one thing from this entire episode, it would be enabling 2FA.

A stolen password becomes useless if the attacker also needs the device in your pocket. Proxmox supports both TOTP (Google Authenticator, Authy, etc.) and hardware keys. I personally run YubiKeys on all production systems and haven’t looked back.

Go to Datacenter ? Permissions ? Two Factor Authentication and set it up for your admin accounts. Takes five minutes. Worth its weight in gold.

Step 5: Make SSH Boring to Attackers

We can take SSH security much further than just disabling root login.

First, I change the SSH port to something non-standard (pick a high port you’ll remember). The automated bots scanning the internet are lazy—they mostly hit port 22. Make them work for it.

But the real move? Kill password authentication entirely.

My process:
– Generate an SSH key pair on my workstation
– Copy the public key to the server
– Test key-based login
– Only then do I set PasswordAuthentication no in sshd_config

The difference is night and day. Your logs become dramatically cleaner, and password-based attacks become impossible.

Step 6: Embrace Your Patching Discipline

Security isn’t a “set it and forget it” sport. It’s a lifestyle.

This is where Proxmox’s repositories matter. In production, I strongly prefer the Enterprise repository. The updates are more thoroughly tested and stable. For labs, the No-Subscription repo works fine, but understand what you’re getting.

Either way, make apt update && apt dist-upgrade part of your regular rhythm. You’re patching both Debian and Proxmox VE in one shot. Do it consistently.

Step 7: Give Your Server an Automated Bouncer (Meet Fail2Ban)

Some attacks are sophisticated. Most aren’t. Most are dumb, noisy, brute-force attempts from script-kiddie bots.

This is why I consider Fail2Ban essential on every Proxmox host.

It watches your log files in real time. When it sees someone failing to log in repeatedly, it automatically updates the firewall to block their IP for a period of time. It’s like having a bouncer who kicks out drunk people trying to force their way into the club.

I configure it to protect both SSH and the Proxmox web interface. Set it and sleep better.

Step 8: Practice Least Privilege Like Your Job Depends On It (It Does)

Finally, let’s talk about other people.

My unbreakable rule: Never give multiple people full administrator accounts. It’s sloppy and dangerous.

Proxmox’s Role-Based Access Control system is excellent here. I create custom roles like “VM Operator” that allow starting, stopping, and viewing consoles—but nothing that touches networking, storage, or cluster configuration.

Then I assign these roles to groups, add users to the groups, and give them access only to their specific pools of VMs. Containment and accountability in one elegant package.

The Foundation Is Now Solid

Let’s recap what we’ve built today:

• No more root SSH access
• Hardened and isolated management network
• Proxmox firewall with default-deny posture
• Two-factor authentication everywhere
• Key-only SSH on a non-standard port
• Regular patching discipline
• Fail2Ban standing guard
• Proper RBAC with least privilege

This isn’t theoretical security. This is practical, production-grade hardening that takes a relatively small amount of time but delivers enormous peace of mind.

Security isn’t a feature you add later. It’s the bedrock your entire high-availability strategy stands on.

Now that our host is secure, the next question becomes: how do we protect the data sitting on that host?

That’s exactly what we’re diving into next time in Episode 9: Proxmox VE vs. Proxmox Backup Server – A Symbiotic Relationship. I can’t wait to show you how these two tools work together to create something truly special.

Until then, go harden those hosts, my friend.

Drop a comment below and tell me: What’s the one security change that gave you the biggest “why didn’t I do this sooner” feeling? I read every single one.

See you in the next episode.

Stay secure out there,
— Your infrastructure mentor