Skip to main content

Hello, everyone!

 

I have been studying and doing some labs to better understand how the immutability on a Linux Repository works.

 

This is my current Veeam Backup & Replication structure:

- 1 Backup Job for VMware VMs;

- 1 windows agent Backup Job for a physical machine;

- 1 Backup Copy job for each of the previous jobs, with the hardened repository as the target.

 

The hardened repository is a Ubuntu 20.04 LTS with a XFS disk. The SSH service is disabled and no gateway is set. The Veeam server was first configured to use a single-use credential.

Everything works great!

 

My question is:

In a scenario where all the VMs, physical servers and Veeam server are lost, where all I have are the immutable backups, how should I approach the repository?

What I did so far was:

- Start the SSH service of the hardened repository, open the port 22 in OS firewall;

- Get a separate windows machine running and install Veeam B&R in it;

When I tried to add the Linux repository to the new Veeam server, it could not connect using the "single-use credential for hardened repositories" option (I verified the credentials and they were correct). When I tried using the same credentials with the "Linux account" option, it worked.

 

How should I approach this type of scenario? Is it ok to use this other account option? Will I need to create another account with the same restrictions as before to set it to "single-use" as it was before? How do I normalize the backup infrastructure after this type of situation?

I logged in as root (sudo su) and changed the password for the root user.

After that the option to use “su” also worked.

 

I will stick to temporarily adding the user to the sudo group, though.

Thank you guys!


Normally when I setup a hardened repository I do it just like that; add the service user to the sudo group and remove it afterwards. When doing upgrades or such I temporarily add it back to this group as you need elevated permissions for the setup/updates.

Regarding your error; I was just able to reproduce this in my lab VM. I think the option tries to su root and Ubuntu doesn’t have a root user by default, therefore it fails. Could be a bug or maybe it’s a known issue; I’ll do some research in the evening.


Sorry for the basic question, but did you give the correct root password when activating the su option?

The single use credentials need the su option and the correct root password. It is no problem, because they are not saved.

I did check the password and it should be correct.

 

One thing that I did was re-add the user to the sudo group and it worked. Is this the right course of action?


Sorry for the basic question, but did you give the correct root password when activating the su option?

The single use credentials need the su option and the correct root password. It is no problem, because they are not saved.


The user is not in the sudo group.

When I try to use it as Single-use, I receive the following message:

If I enable the ‘Use “su” if “sudo” fails’ option, the message changes to:

 


You should be able to reconnect an existing hardened repository with single-use credentials to a new/different installation. I don’t see a reason why it shouldn’t work with single-use, but work with the regular linux account.

Is there anything special about the user, like is it “root” or did you remove it from the sudo group?

Could you post an error message or screenshot from what you’re seeing with the single-use credentials?


Comment