Hardened repository looses connection to veeam

[yzfr6]

I'm having an issue with several different customers where the hardened Linux repo is losing its connection to the Veeam server after several days and no changes have been made it just stops working. To resolve I have to ssh in and disable MFA and then elevate the veeeam user that I'm using for the single use credentials and then rescan in Veeam. After it picks back up and starts working I demote the veeamuser account and enable MFA. The issue is that is keeps repeating again. Has anyone seen this before? Is there an adjustment I can make to prevent this from happening and still keep MFA on for SSH as well as keeping the veeam users permissions as a minimum?

[Regnor]

What error do you see when the repository gets inaccessible? Is the Veeam transport service still running on you repository in that moment?

[yzfr6]

It shows as unavailable and when I go to rescan it:

12/7/2022 10:05:59 AM Error [x.x.x.x] Refresh Linux host failed Error: No connection could be made because the target machine actively refused it x.x.x.x:6162
12/7/2022 10:07:35 AM Error Failed to rescan repository Veeam 2 Immutable Backup Repository 1 Error: No connection could be made because the target machine actively refused it x.x.x.x:6162


As soon as I disable MFA and elevate the account it works again but I'd like to be able to keep it with least privileges and have MFA on.

[Regnor]

After the initial setup, the user account isn't used anymore to connect to the repository. You wrote it, but are you sure that you've setup the repository with Single use credentials?

Is the Veeam Sevice still running on your repository at that time (service veeamtransport status)?

And is there anything useful logged (journalctl; /var/log/VeeamBackup)?

[yzfr6]

Yes I'm 100% sure that its using single use.

I should mention that as part of "fixing" it I need to go back to managed servers and reenter the credentials and have it scan\setup the server again. It may be service is not running and that process just starts it again. I dont have the server having the issue at the moment but next time it happens I'll check the veeamtransport service to see if that is the issue and review the logs and report back.

[karsten123]

which linux distro are you using?

[Regnor]

Maybe the logs I've mentioned include some historical information on what's happening on your server.

[HannesK]

Hello,

Is there an adjustment I can make to prevent this from happening and still keep MFA on for SSH as well as keeping the veeam users permissions as a minimum?

do you have MFA only for SSH, or also for local logins?

SSH is only used for installation / upgrade. You can even disable SSH during normal operations.

Overall, MFA seems to do exactly what it should do

Best regards,
Hannes

[yzfr6]

I'm running Unbuntu LTS 22.04.1 and after a bit more investigation after another failure I found that the veeamtransport.service is failed. If I start it up again all looks good. How do I pull the logs to see what is causing the failure?

[Regnor]

Did systemctl status veeamtransport show anything useful? If not check journalctl and /var/log/VeeamBackup.

[HannesK]

Hello,
I repeat my question...

do you have MFA only for SSH, or also for local logins?

Thanks,
Hannes

PS: Ubuntu 22.04 is only supported in V12 (although working fine in V11 as far as I can see)

[yzfr6]

MFA is only on for SSH.

[HannesK]

then it makes no sense to me, because SSH is not used. You can disable SSH completely after deployment. It's only needed for upgrade to V12. Once you are on V12, SSH is not needed anymore for upgrades. With V12, SSH is used only for installation.