Stashboard V6.6 adds a proxmox lxc console browser shell: a real, interactive terminal running inside one of your LXC containers, opened from a browser tab with no SSH client and no separate Proxmox session. It is also, without much competition, the most dangerous surface in the entire product — so this guide spends more time on the threat model than on the button. 🔐
Everything else in the dashboard is read-mostly or narrowly scoped. A shell is not. A proxmox lxc console browser session is arbitrary code execution inside a container, launched from a web page. That deserves an honest explanation of how it is gated, how it is transported, and how it is recorded — not a screenshot and a changelog line.
What the Proxmox LXC Console Browser Actually Does
V6.6 puts a Console tab on the Proxmox container modal and a console button on each LXC card. Clicking either opens an xterm.js terminal in the browser, attached to a live shell inside that container.
Under the hood there is no magic and no agent installed in the guest. Stashboard SSHes to the PVE host you already configured, then runs:
pct exec <vmid> -- /bin/bashThat is it. The pct command is Proxmox’s own container tool, running as root on the node, executing a shell in the container’s namespace. The proxmox lxc console browser layer is a transport and an authorization wrapper around that one command — it does not invent a new privilege path, it exposes an existing one deliberately.
The command defaults to /bin/bash and is editable per session. Alpine-based containers, which ship without bash, want /bin/sh instead. You set it before the socket opens, not after.
Why a pct exec Web UI Follows the Update Count
This feature exists because of the gap the previous release left open. Stashboard already tells you how many updates each LXC has pending — “pihole has 7 updates pending”, right there on the card.
Then what? Before V6.6: open a terminal, SSH to the node, pct enter 103, apt upgrade, exit, go back to the browser, refresh. The dashboard told you about a problem it could not help you fix.
A pct exec web ui closes that loop. You see the count, you open the proxmox lxc console browser, you upgrade, you watch the count drop. Same tab, same session, same auth. That is the whole product argument — and it is a natural extension of the broader goal of managing Proxmox from a web dashboard.
The Threat Model Behind the Proxmox LXC Console Browser
Here is what you are actually authorizing when you turn this on. Be clear-eyed about it. ⚠️
pct exec runs from the PVE host as root. Inside a standard privileged LXC, the resulting shell is root in that container. Anyone who can open a proxmox lxc console browser session against a container can read every file in it, rewrite its config, install packages, exfiltrate its secrets, or delete it from the inside. For an unprivileged container the blast radius is smaller but still total within that guest.
So the realistic attack paths are:
- A stolen dashboard session. If someone has your Stashboard session, the console turns “read my homelab status” into “run commands in my homelab”.
- A malicious page or cross-origin request trying to open a socket on your behalf.
- A curious or careless second user on a multi-user install, poking a container they should not touch.
- A leaked or replayed connection URL. Terminal transports that put reusable credentials in a query string are a classic own-goal.
- An abandoned tab. A session left open on an unlocked laptop is a standing root shell.
Every design decision below maps to one of those. That is the point of writing the threat model down first: the mitigations stop looking like paranoia and start looking like arithmetic.
Three Gates, All Required, Off by Default
The proxmox lxc console browser is disabled out of the box. Upgrading to V6.6 does not hand anyone a shell. Three independent gates must all be open:
- The master switch.
Settings → LXC console, DB-backed, instance-wide. One place to kill the feature entirely. - Per-host opt-in. Each Proxmox host has its own “Allow LXC console” setting. Enable it on the lab node, leave it off on the one running anything you care about.
- SSH credentials on the host. No stored credentials, no transport, no console.
Miss any one of them and the proxmox lxc console browser simply does not open. The critical detail: missing any gate refuses the ticket server-side. This is not a hidden button. Hand-crafting the API call against a host with the console disabled gets you a refusal from the server, not a shell. Client-side gating is decoration; the check lives where it cannot be edited with devtools.
⚠️ Enable per-host deliberately. The master switch is convenient, but the per-host opt-in is where the real scoping happens. Turning it on for every host because it was faster defeats the design.
Tickets and Sockets: How the Self-Hosted Proxmox Shell Connects
The transport under the proxmox lxc console browser is not new code written under deadline. It is the same mechanism proven by the V5.3 host terminal and the V5.7 container exec, reused here for LXC guests.
Opening a session is two steps:
- An authenticated POST to
.../lxc/{vmid}/console/ticket. The server validates all three gates, then mints a single-use, short-lived ticket that binds the command server-side. - The WebSocket opens at
.../console/ws?ticket=....
Two properties matter here. Single-use and short-lived means a captured URL is worthless — the ticket is spent the moment the socket attaches, and it expires on its own if it is never used. The command is bound server-side means the shell you asked for in the POST is the shell you get. You cannot smuggle a different command in through the socket URL, because that URL carries a ticket, not a command. That closes the injection path a naive ?cmd= design would open wide.
One honest limitation: live terminal resize is not available over SSH. The PTY is sized when the session connects. Drag your window mid-session and the geometry will not follow. Size the window first, then connect — especially before running anything full-screen like htop or nano.
Every Proxmox LXC Console Browser Session Is Audited
A self-hosted proxmox shell that is not logged is a shell you cannot reason about after the fact. Every proxmox lxc console browser session writes a ProxmoxConsoleSessions row recording:
- Who opened it and when
- Which host, node, and guest
- The command that was run
- Duration, bytes in and out, and the end reason
You read these under Settings → Audit → LXC console. Byte counts will not tell you which commands were typed, but a 4-second session with 30 bytes and a 40-minute session with 8 MB of output are very different events, and you can tell them apart at a glance.
Two more controls run server-side, independent of the browser:
- Concurrency caps, per-user and per-host. One person cannot open fifteen root shells at once.
- A server-side idle timeout. Idle sessions close regardless of the client. Closing the laptop lid does not leave a shell parked forever.
That last one directly answers the abandoned-tab risk. In a proxmox lxc console browser session the server owns the lifecycle, not the tab.
When to Use the Console vs SSH to the Host
The proxmox lxc console browser is not a replacement for a terminal. It is a shortcut for a specific shape of task.
Use the console when the work is inside a single container and short: apt upgrade after seeing an update count, restarting a service, tailing a log, checking why a config did not apply, confirming a fix landed.
SSH to the host when you need anything the container cannot see. Creating or destroying containers, editing configs in /etc/pve/lxc/, moving storage, working on the node’s ZFS pools, debugging networking from the bridge side. Those are host operations — pct exec runs inside a guest, so it structurally cannot do them. (Container creation has its own web UI path anyway.)
Reach for a proper terminal when the session will be long, needs a stable window size, involves file transfer, or you want tmux, port forwarding, or scrollback you control. The missing live resize in the proxmox lxc console browser alone makes long full-screen work uncomfortable.
Rule of thumb: if you would have typed pct enter anyway, the console saves you three steps. If you would have typed anything else, SSH.
Turning the Proxmox LXC Console Browser On, Carefully
A sane rollout order for the proxmox lxc console browser:
- Confirm SSH credentials work for the host — the existing host terminal is the fastest check.
- Flip the master switch in
Settings → LXC console. - Enable “Allow LXC console” on one host. The least important one.
- Open a console on a container you would happily rebuild. Try
/bin/shif it is Alpine. - Check
Settings → Audit → LXC consoleand confirm your session is recorded correctly. - Only then widen it.
⚠️ If step 5 shows nothing, stop and investigate before enabling more hosts. Auditing that does not work is worse than no auditing, because you will trust it.
The Broader Point
Shipping a browser shell is easy. Shipping one you can defend is the work: default-off, three independent gates, server-side enforcement, single-use bound tickets, concurrency caps, idle timeouts, and a complete audit trail. A proxmox lxc console browser is the feature most likely to be regretted if built casually, which is exactly why it was built this way.
If you are new to the project, Stashboard is a self-hosted homelab service dashboard — and the proxmox lxc console browser is one tab in a much larger picture. 🚀