A couple of questions on future version enhancements

[derr7]

Is there any timeline for the addition of an API by Proxmox to make these connections?

The current system that SSHs into each Proxmox node every 60 seconds (yes every 60 seconds,) is causing alot of system log spam (each of these connections produces 20+ lines in the system logs,) and is making it harder for us to deal with log management on our nodes. Is it really necessary to connect every 60 seconds to each node, anyway? Is there a way to turn this off? I would prefer for it to just check in when it has to or on a much, much longer time delay than this. Its basically using SSH as a heartbeat, or collecting a status or something. Why is that necessary?

#MOD: Second question moved to existing topic

[rovshan.pashayev]

Hi,

Regarding SSH — this behavior is not related to Veeam. Proxmox VE currently lacks the necessary APIs, so the integration relies on SSH.

[derr7]

Appreciate the response. Is every 60 seconds necessary though? Just seems like a lot to be doing in the background when there is literally nothing backing up and nothing scheduled.

[rovshan.pashayev]

Hello,

To help mitigate this, please open a Support Case and share the case number here for reference.

[Figataur]

Came here to #MeToo this. We have just set up a simple VM backup job for a new Proxmox node, added to our several ESXi nodes, and already the SOC&SIEM team are going bananas about being flooded with hundreds of alerts and warnings about "suspicious network behaviour" because there are root ssh logons going on across the network every 60s!

Let's be honest that using root ssh logons for a 60s heartbeat is nuts. Using any kind of ssh logon for heartbeat is a bit nuts, but at the very least if this needs to happen because Proxmox don't have the relevant API (which I'm very surprised at, because the Prox API is fairly extensive; what exactly are you polling for every 60s that the other API features don't satisfy?) then it should use a de-elevated user that has only the relevant read permissions on the Prox server. But why does there need to be a heartbeat at all here anyway? As long as the resource is alive when the backup is scheduled, what's the problem?

[Figataur]

I have created support case #07990865 for this.

[rovshan.pashayev]

Hi,

Thanks for the feedback — a couple of points to clarify.

We do not require root‑only access. We support both root and a sudoer / least‑privilege approach. Please refer to our KB with the recommended configuration and permissions here: https://www.veeam.com/kb4701

The periodic SSH check is not intended as a simple or unnecessary heartbeat — it serves as an early availability indicator. From our perspective, a host being “available for backup or restore operations” means that SSH access is available, as job execution depends on it.

We do agree that SOC/SIEM noise should be addressed.
The recommended approach is to use a dedicated service account (sudoer with minimal permissions) and to tune detections so this activity is treated as expected management traffic (based on source, target, account, and cadence).

As you have already opened a Support Case, please continue working with the Support team and await their guidance.

[Figataur]

Thanks very much for that - somehow I didn't find that KB page when searching. We have now created the veeamdep user and set the heartbeat to 10 mins, so we've gone from 1,440 network root logins per day to 144 regular user logins, which is fine

The KB page isn't quite complete - we needed to add the following command to the sudoers file as well, to fix an error at backup time:

Code: Select all

/usr/bin/rm /var/lib/vz/VeeamTmp_100__*.qcow2

We were able to create a Veeam backup overnight, which was great; although we are still getting a number of unusual login errors at backup time back from Veeam on our domain to do with user "X509N" which we don't fully understand and need to resolve...

[Figataur]

The X509N thing is a known issue here:

veeam-agent-for-windows-f33/veeam-tryin ... 79771.html