A Stray Ctrl+Alt+Del Rebooted My Proxmox Host: Here's How I Made It Behave Like ESXi

A field note from a Proxmox VE 9.2 host: one three-key combo at the login screen, an instant reboot with VMs running, and the two systemd settings that turn every keyboard path to a reboot off.

The setup

I pressed Ctrl+Alt+Del at the login screen of our Proxmox host. As a test. I expected a warning screen, or nothing at all. I got a reboot. The whole host, down and back up in under two minutes, while the always-on VMs got yanked with it.

No harm done this time: it's our backup and disaster-recovery box, still being built out, and every VM auto-started on boot like it was supposed to. But that's exactly the problem. This box ships to a client as their recovery hypervisor. It will spend its life running VMs that matter, and its console is the place you end up standing when the network is down. The last thing that surface should carry is a keyboard shortcut that reboots the estate.

For contrast: I've spent years on ESXi, and its console (the DCUI) has this right. Rebooting an ESXi host from the physical console means pressing F12, logging in as root, and then choosing to reboot, deliberately. A stray Ctrl+Alt+Del at the ESXi login screen does nothing at all. Proxmox's console, stock, is the opposite.

What's actually happening

Proxmox is Debian with a hypervisor on top, and Debian is systemd. systemd watches the console for the Ctrl+Alt+Del combo. When it sees it, the kernel flags PID 1, and systemd responds by starting a unit called ctrl-alt-del.target. On a stock install that unit is a symlink straight to reboot.target:

$ ls -l /usr/lib/systemd/system/ctrl-alt-del.target
lrwxrwxrwx 1 root root 13 Apr 13 /usr/lib/systemd/system/ctrl-alt-del.target -> reboot.target

That's the entire mechanism. There's no confirmation screen, no safety, no "are you sure." The keyboard combo is wired to the reboot target, and the login screen sitting in front of it changes nothing, because the combo is caught below the login prompt, at the systemd level.

The fix

One command, run as root on the host:

systemctl mask ctrl-alt-del.target

Masking replaces the unit with a dead stub (/etc/systemd/system/ctrl-alt-del.target -> /dev/null). systemd refuses to start masked units, so when the keypress arrives, the start attempt fails silently and nothing happens. The combo stops being a reboot trigger and becomes a no-op.

Verify it took:

$ systemctl status ctrl-alt-del.target
○ ctrl-alt-del.target
     Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.)
     Active: inactive (dead)

That's the test. Loaded: masked is the whole proof. I did not verify this by mashing the keys on a box with VMs running; I'd already rebooted it once today by accident, and the status line is a cleaner test than a second reboot.

Notes on behavior:

It takes effect immediately. No restart of the host, no daemon-reload, no reboot needed. The next keypress on the console hits the masked unit.

It survives updates. The mask lives in /etc/systemd/system/, which wins over the packaged unit in /usr/lib/systemd/system/. Proxmox upgrades can refresh their defaults all they want; your mask stands.

Legit reboots still work. systemctl reboot, the web UI, and every normal shutdown path are untouched. You're breaking the surprise path, not the reboot path.

You don't get ESXi's confirm-first UX. systemd won't pop a "press again to confirm" dialog at the console. The options are reboot-on-press or nothing-on-press. For a hypervisor, nothing is the right default. If I need the host down, I'll type the command.

The one thing masking doesn't stop

There's an escape hatch, and it's documented, and it's deliberate: if PID 1 receives the Ctrl+Alt+Del signal more than 7 times within 2 seconds, systemd triggers an immediate, non-graceful reboot. That's the recovery path for a hung host, and the mask doesn't touch it.

Read that as: a single accidental press is now fully covered. Mashing the combo seven-plus times inside two seconds will still hard-reboot the box, because that's systemd telling you it assumes you're reaching for the reset button on purpose. An accidental press doesn't come close to that pattern.

But it's not untouchable either. Since systemd 232, the mash path has its own switch: CtrlAltDelBurstAction= in/etc/systemd/system.conf. The stock line ships commented out, which means the default reboot-force is what you're running. Set it to none and the seven-presses-in-two-seconds pattern does nothing at all, the same way the mask made the single press do nothing. After that, the keyboard has no path to a reboot on the host, period.

# /etc/systemd/system.conf.d/99-ctrl-alt-del.conf
[Manager]
CtrlAltDelBurstAction=none

# applies live, no reboot needed
systemctl daemon-reexec

The escape hatch isn't gone, it moved. Magic SysRq was already armed on my box (sysrq at 438, reboot bit included), so a hung host still answers Alt+SysRq+REISUB or Alt+SysRq+B, and there's always the reset button. The difference is posture: clumsy keyboard work does nothing, deliberate action still gets you through. That's the ESXi philosophy, arrived at twice.

Since this went live, I've tested it the old-fashioned way: deliberate mashing on the hardened host, the kind of input an accident never produces. Nothing happened. The config says none; the console agrees.

What I'd tell someone else

A hypervisor console should not carry a live reboot trigger. ESXi treats the physical console as a surface that requires login and confirmation for power actions. Stock Proxmox treats it as a keyboard shortcut to reboot.target. One of these designs can be tripped by a keyboard bump.

The fix is two settings and reversible. systemctl unmask ctrl-alt-del.target, removing the drop-in, and one more systemctl daemon-reexec put the stock behavior back. Nothing needs a restart, either way.

Don't test it by pressing the keys on a production box. The status line is the test. I speak from recent experience.

Do it before the box is in production. This is a two-minute hardening step that's worth folding into any Proxmox build where the console is reachable and the VMs matter. That description covers basically every Proxmox build.

The commands

# 1. See what the combo is wired to today (stock Proxmox: reboot.target)
ls -l /usr/lib/systemd/system/ctrl-alt-del.target

# 2. Mask it. PID 1 refuses to start a masked unit, so the key press does nothing.
systemctl mask ctrl-alt-del.target

# 3. Verify. You want this line:
#    Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.)
systemctl status ctrl-alt-del.target

# 4. Also close the mash escape hatch (7+ presses in 2s). Drop-in:
mkdir -p /etc/systemd/system.conf.d
{
  echo '[Manager]'
  echo 'CtrlAltDelBurstAction=none'
} > /etc/systemd/system.conf.d/99-ctrl-alt-del.conf

# 5. Apply live. Re-executes PID 1 in place, no reboot, VMs unaffected:
systemctl daemon-reexec

# 6. Verify. You want this to print s "none":
busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager CtrlAltDelBurstAction

# Undo anytime. Restores the stock Debian behavior (reboot on press and mash):
# systemctl unmask ctrl-alt-del.target
# rm /etc/systemd/system.conf.d/99-ctrl-alt-del.conf
# systemctl daemon-reexec

The host is back to normal: VMs running, pool healthy, and the console no longer has a live grenade wired to three keys. The panic mash doesn't work either. ESXi has had this right for years. Proxmox is two settings away from the same posture, and now it stays that way.

Test environment: Proxmox VE 9.2.x (Debian 13 base, systemd 257), HP Z6 G4 tower, local physical console and keyboard, October 2026. The reboot that inspired this was a single test press at the login screen; all VMs auto-started on boot; zero data exposure. The CtrlAltDelBurstAction=none change was applied and re-exec'd live on the same host; live manager value verified over busctl (prints s "none").