Adding Ubuntu Server for NAS backup fails

[JonJR]

Just trying out the NAS backup on a Ubuntu 18.04 file server, but having some issues:

Backup Infrastructure->Managed Server->Linux->Add

The server gets added with the warning:

Code: Select all

Linux Host 'files11.xxx.au' was created with warnings. See logs for details.
SSH options:
	User: vroot
	Elevate account privileges automatically: yes
	Add account to the sudoers file: no
	Use “su” if “sudo” fails: no

If I rescan the server I get
Unable to collect hardware info

If I try to add a fileshare I get:
Failed to determine if the fileshare uses 64-Bit OS

And can confirm that the vroot user does have sudo:

Code: Select all

root@files11:~# cat /etc/sudoers.d/10_vroot
vroot ALL=(ALL:ALL) NOPASSWD: ALL

Any ideas?

[Dima P.]

Hello,

Can you please check if you can connect to this Linux box via Putty from the Veeam B&R server under vroot? Thanks!

[JonJR]

For that account, no it was using a certificate which only Veeam knows the private key for. So I created a regular password account (with sudo) on the server and I can putty to the server and sudo to root, but when I use use this account in Veeam I still get the same error messages.

[Dima P.]

Can you please make sure that the required range of ports are opened between linux machine and Veeam B&R server? Cheers!

[DerOest]

Hello there, we faced the exact same error.

In our case, it was Veeam trying outdated encryption methods, therefor not able to install required components.
It only tries to install that when ADDING THE MANAGED LINUX SERVER, not when rescanning.

You can check that - /var/log/messages or /var/log/syslog or wherever your disto logs to: There will be ssh connection errors - very obscure, because a lot of other connections actually work! It's only 1 or 2 tries that fail (Veeam seems to use different SSH-settings for different tasks!). The error only pops up when you try to add the server as a new managed linux server, not when rescanning it etc.

If that's the case, you'll have to edit the sshd config, reload ssh, delete the managed linux server and readd it.

Here's the part of our sshd config:
# Specifies the available KEX (Key Exchange) algorithms. //recommended von Mozilla
#KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group1-sha1

#MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-sha1


These are mentioned here: https://helpcenter.veeam.com/docs/backu ... ml?ver=100
and here: https://www.veeam.com/kb2061


Isn't SHA1 outdated by now? Why is 1 or 2 specific connections failing when adding a managed linux server, while all other ssh sessions seem to work fine (evidenced by the ssh logs, as well as /tmp/veeam* folders being created)

[JonJR]

In our case, it was Veeam trying outdated encryption methods, therefor not able to install required components.
It only tries to install that when ADDING THE MANAGED LINUX SERVER, not when rescanning.

Thanks for the input, unfortunately, whilst we did get this error message in /var/log/auth
Feb 24 10:27:48 files11 sshd[95278]: Unable to negotiate with 10.x.x.x port 50495: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 [preauth]

Adding the DH SHA1 to openssh did remove the error message in the log, but it didn't fix the issue. Also looking at the Veeam KB2061, we had other KEXs listed in openssh, so maybe that error message was a red herring (at least for us).

Looking at the Veeam Agent logs on the managed server I can see a few warnings:
/var/log/veeam/veeaminstaller.log
WARN|Failed to call 'veeamsnap-loader' utility.

I've put in a support ticket : Case # 04021797

[DerOest]

Hi JonJR,

it's not clear from your posts, so just double checking:
After changing the sshd config, did you delete the managed Linux server in Veeam again and readd it?
I needed to change 2 settings in sshd and found out only one after the other.

After i fixed the KexAlgorithms, i needed to add the MACs entry - so only on the 3rd try of adding the server did it work...

[JonJR]

Wow, that was annoying to resolve, it was nothing to do with ssh at all, instead it was the firewall!

As per https://helpcenter.veeam.com/docs/backu ... ml?ver=100 the Linux server needs both ports 2500-3300 to the B&R server AND the B&R server needs the same ports open to the Linux server.
All of our exisiting agents are Windows and I assume that the agent does the Windows firewall for us, but on our Linux servers we Puppet IPTables, so the ports were open.

-A INPUT -s 10.x.x.x/32 -p tcp -m multiport --dports 2500:3300 -m comment --comment "001 accept inbound Veeam Agent Backup Range" -j ACCEPT
Will do the trick!

[Dima P.]

Jon,

Thanks for sharing and sorry for the confusion. We've already asked technical writers to update the Help Center with all ports being listed (incoming and outgoing). Cheers!