ProxTrace
GitHubPublic repository coming soon Open console

Proxmox VE access audit log: who logged in, from where, how

Proxmox VE logs web interface logins and authentication failures in each node’s system journal, SSH logs its own, and each node keeps a task history with the account that started each task. It does not keep an audit log of accounts, though: creating a user or changing a role or ACL leaves no dedicated trace. Tracing access therefore means gathering these sources, keeping them off the nodes and linking them together.

By Pepiva Technology · Published · Updated

The four ways in

Before looking for traces, list the ways someone can act on a Proxmox VE cluster:

  • The web interface and API, on port 8006, with an account from a realm (PAM, Proxmox VE, LDAP, Active Directory, OpenID Connect) and possibly a second factor;
  • API tokens, sent in the Authorization: PVEAPIToken=USER@REALM!TOKENID=UUID header by automation, monitoring or backup tools;
  • SSH on the nodes, used by administrators and, between nodes, by the cluster itself;
  • guest consoles (noVNC, SPICE, terminal), opened from the interface.

Each one leaves different traces, in different places, and sometimes none.

Web interface and API logins

Authentication failures are written by the pvedaemon service to the systemd journal, with the source address and the account tried. It is the very line the fail2ban page of the Proxmox wiki uses to block brute-force attacks:

journalctl _SYSTEMD_UNIT=pvedaemon.service | grep "authentication failure"

Successful logins also appear in the Proxmox VE service logs. The pveproxy access log, /var/log/pveproxy/access.log, also records every HTTP request received by the interface and API, with its source address: that is where you find the activity of a tool using a token, since it never goes through the login screen.

The systemd journal has been enabled by default since Proxmox VE 4.0 and kept across reboots since 7.0; how long it is kept depends on the space allocated to it on each node.

SSH logins

SSH logins are logged by the sshd daemon in the same system journal:

journalctl _COMM=sshd --since "2026-10-01"

Tell administrators’ logins apart from the ones nodes open to each other to run the cluster: the latter are normal and frequent, and drown the former unless you filter on the source address. A named account per administrator, rather than a shared root, is what makes an SSH login point to a person.

Consoles and tasks

Opening a console on a guest and operations started from the interface (start, migration, backup, change) are tasks, recorded on the node concerned with the account that started them:

pvenode task list --userfilter john@pve
pvenode task list --vmid 104 --typefilter vncproxy

The task history answers “who did what on this machine”, not “who logged in”. For the details of a configuration change, see who changed this VM?

External realms: LDAP, Active Directory, OpenID Connect

When accounts come from a directory, identity is managed outside Proxmox VE, but rights are still granted in Proxmox VE. Groups synchronised with pveum realm sync <realm> are written to /etc/pve/user.cfg. Two consequences for traceability: a departure must be handled in the directory and checked in Proxmox VE, where a local account or a token can outlive the directory account; and logins must be matched with the directory’s logs, which requires shared clocks.

Second factor and lockouts

The second factor also changes what you read in the traces. After eight failed TOTP attempts, the account’s TOTP factors are disabled; for WebAuthn and recovery keys, a hundred attempts block all second factors for an hour. A locked account signals either a lost device or an attempt with a password the attacker already knows: either way, it deserves a check before unlocking.

pveum user tfa list
pveum user tfa unlock john@pve

No audit log for accounts and permissions

In February 2026, on the Proxmox forum, a team wanting to ship Proxmox VE 8.4 and 9.1 logs to a SIEM made this observation: SSH, PAM and interface logins (successful or not) are visible, but not the creation or deletion of a user, nor a change of role, permission or ACL, whether in the tasks, the system log or the cluster log. Another participant summed it up: there is no audit system in Proxmox VE at the moment.

In practice, to know who was given administrative rights and when, you have to compare successive records of accounts and ACLs (pveum user list --full, pveum acl list), dated and kept outside the cluster. The content of the files involved, such as /etc/pve/user.cfg, describes the present state, not how it evolved. ProxTrace fills this gap, as described below.

Keep and centralise

Traces left on a node do not last: they rotate with disk space, disappear with the node, and an intruder who obtained administrative rights can erase them. The participants in that thread forward logs with rsyslog to a central server or a SIEM, a solution they found imperfect but workable.

  • Send each node’s system journal (at least pvedaemon, pveproxy and sshd) and the pveproxy access log to a server outside the cluster.
  • Keep node clocks synchronised: without a common time, you cannot match a failed login with a task.
  • Export the list of accounts, tokens and ACLs at regular intervals, so a change of rights can be dated.
  • Set retention according to your obligations, and check that it covers the period an audit will ask about.

What to watch first

  • repeated authentication failures from the same address, and those targeting root@pam;
  • a successful login from an address outside the management network;
  • logins by dormant accounts or by people who are supposed to have left;
  • a token used from an unusual address, or after its planned removal date;
  • a new administrator account, or an existing account suddenly granted Administrator on /.

The settings that reduce these risks (second factor, management IPSet, filtered SSH, dated tokens) are detailed in the Proxmox VE hardening checklist; the security audit guide shows how to check that they are in place.

Investigating a suspicious login, step by step

  1. The failures: in the pvedaemon journal, attempts from the address in question, the accounts targeted and the period.
  2. A success? A successful login from the same address, or right after a series of failures on the same account.
  3. What followed: in the pveproxy access log, the requests from that address after the login.
  4. The actions: pvenode task list --userfilter on each node for the account concerned, over the same window.
  5. The rights: compare the records of accounts, tokens and ACLs before and after, to spot an added account or token.
  6. Contain: disable the account (pveum user modify <account> --enable 0), delete its tokens, change exposed secrets, then record the timeline and what remains a deduction.

What ProxTrace adds

ProxTrace brings these sources together in one timeline:

  • tasks, API calls, logins and logs become events linked to the node and machine concerned, with filters by account or token, source address, operation and period;
  • Proxmox VE users, groups, roles and permissions (ACL) are compared from one collection to the next: each change becomes an event that keeps the before and after state, and the notification names the entries added or removed. It is the audit log of accounts and rights that Proxmox VE does not keep; the cluster and node firewalls are tracked the same way;
  • a login is matched to an account only when the match is unique, and it is then marked “Correlated”: the tool does not guess who was behind an address;
  • items that need action, including the “Proxmox access” category, land in the attention queue with their evidence;
  • the checks cover, among other things, authentication failures, dormant accounts and API tokens;
  • the history is kept by ProxTrace, off the nodes, and its agent only reads.

The data collected and the agent’s rights are detailed on the collector security page.

Sources