Learn Proxmox VE - Proxmox Node Security Hardening

#Introduction

Episode 14 secured user access. Episode 15 secures the node itself: the SSH entry points, the web UI, and the update mechanism. These are the defense layers attackers test most often — and that administrators ignore most often.

We'll disable password login for root, change the SSH port, replace the self-signed certificate with a valid TLS one, restrict web UI access to a management VLAN, and then automate security updates. By the end of the episode, your node will be far harder to break into.

#Securing SSH Access

#SSH Key Only Authentication

The first step is to disable password-based login for root. Passwords can be guessed or brute-forced; SSH keys are nearly impossible to guess. Create a key on your work machine, then copy it to the node:

ssh-copy-id root@192.168.1.10

Once the key is installed, verify that key login works, then disable password login in /etc/ssh/sshd_config:

PermitRootLogin prohibit-password
PasswordAuthentication no

The sshd -t command validates the configuration before the reload, and systemctl reload ssh applies it. Don't close the existing session until you've confirmed key login works.

#Changing the Default SSH Port

Changing the SSH port from 22 to something else reduces the noise from automated attacks targeting the default port. Edit the Port 22 line to a new port, for example 2222:

Port 2222

Don't forget to open the new port in the firewall and close the old one. Also remember to update your SSH client with the -p 2222 flag.

#Restricting SSH Access IPs

The strongest step: restrict SSH to only specific IPs. Use a firewall rule or hosts.allow so only the management network can access the SSH port.

#Securing the Web UI

#Valid TLS Certificates

The default Proxmox web UI uses a self-signed certificate — the browser always warns, and the connection can't be verified. Replace it with a valid certificate from Let's Encrypt or an internal CA.

Obtain the certificate -> upload to /etc/pve/local -> select it in the UI -> reload pveproxy

For Let's Encrypt, you need a domain and DNS or HTTP challenge. Once the certificate is installed, systemctl reload pveproxy makes the web UI serve connections the browser trusts.

#Restricting Access to the Management VLAN

A certificate is useless if the web UI is open to the whole world. Restrict port 8006 access to only your management VLAN. Use the Proxmox node firewall or an external firewall to deny access from other networks.

Allow : 10.0.0.0/8 (management VLAN) to port 8006
Deny  : all other addresses

The combination of a valid certificate plus network restriction makes the web UI accessible only from where it's supposed to be.

#Automatic Security Updates

#Configuring unattended-upgrades

Debian provides unattended-upgrades to install security patches automatically. Proxmox enables it for the enterprise repository; you need to add the pve-no-subscription repository:

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Configure the security update sources in /etc/apt/apt.conf.d/50unattended-upgrades, making sure the pve-no-subscription line isn't commented out. Debian and Proxmox security patches will be installed automatically.

#Monitoring Automatic Updates

Check whether automatic updates are running:

unattended-upgrade --dry-run

The unattended-upgrade --dry-run command simulates the process and shows the packages that would be updated. Check the /var/log/unattended-upgrades/ log occasionally to make sure there are no failures.

#Verifying the Hardening Results

#Auditing the SSH Configuration

After all the changes, make sure no gaps were missed:

sshd -T | grep -E "permitrootlogin|passwordauthentication|port"

The output should show permitrootlogin prohibit-password, passwordauthentication no, and the changed port.

#Checking Open Ports

Review the list of ports actually listening on the node:

ss -tlnp

The ss -tlnp command shows all listening ports along with their processes. Compare them with the ports actually needed: 8006 for the web UI, the new SSH port, and the Corosync and Ceph ports if you use a cluster.

#Closing

Episode 15 strengthened the node's defenses: disabling SSH password login and using keys only, changing the SSH port, restricting access IPs, installing valid TLS certificates for the web UI, restricting access to the management VLAN, and automating security updates.

The key takeaways:

• Disable SSH password login; use SSH key only.
• Change the SSH port and restrict which IPs can access it.
• Replace the self-signed certificate with valid TLS from Let's Encrypt or an internal CA.
• Restrict web UI 8006 access to only the management VLAN.
• Enable unattended-upgrades for automatic security patches.
• Verify all changes with sshd -t and unattended-upgrade --dry-run.

In the next episode, episode 16, we will cover GPU passthrough and nested virtualization — giving VMs direct access to physical devices through IOMMU, bypassing the host driver for NVIDIA and AMD GPUs, and enabling virtualization inside a VM. Your node is hardened; now it's time to maximize the hardware!