8 gems in Veeam Availability Suite V8. Part 1: linux certificate-based authentication

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

(note: this post also appears on the official Veeam blog)
Also available in this series:
Part 2: Quick Rollback
Part 3: Quick Backup
Part 4: support for vSphere tags
Part 5: Snapshot Hunter
Part 6: Tape Server
Part 7: Save as Default
Part 8: Hyper-V

Veeam Backup & Replication v8, part of Veeam Availability Suite v8, has just been released and customers and partners are already starting to upgrade their environments and explore the several new features that have been added to this latest version of the software. As in any previous release, in addition to the main new features that have been promoted during the launch campaign, there are many enhancement that are not part of the marketing activities, but nonetheless they all contribute to create every time an awesome version of the software.

This time, again, the Veeam development team was able to “squeeze” an insane amount of enhancements and new exciting features in this release. And as always, trying to pick the most interesting ones was a challenging task for me, even more than in the past. To align with the version number, I tried to pick my favourite 8 new enhancements, but honestly I would have had a better luck if it would have been Veeam Backup & Replication v20 or v30…

Anyway, after sadly kicking out many of the enhancements from my personal list (but I really invite you to read the complete What’s New Document as almost any new enhancement is worth a read, and there are more than 200 in this release), I figured out which ones are my favourite 8 gems. In this series of posts, I will show you them and dive a little bit into their technical details.

Linux certificate-based authentication

If you have ever worked in a pretty large Linux environment, you have realized one thing for sure: few administrators login into those Linux servers using usernames and passwords. There are several reasons for this: the first one it that most of the times there is no centralized credential management (some are using Microsoft Active Directory via Kerberos, or other solutions, but it’s not so common in my experience), so configuring and even more managing credentials on many Linux machines can become painful. Also, in order to be secure, passwords should be really complex and changed often. But then password management itself can become a cumbersome activity, and administrators start cheating on their own procedures (simple passwords or password without expiration), thus decreasing the security of their own environment. But there is an even more compelling reason: machine-to-machine communications. In order to automate procedures involving different servers, passwords needs to be saved somewhere so scripts and applications can use them to connect to other servers; and if the password is not stored in a secure way like in a text file, it can be compromised.

For all these reasons, Linux administrators often configure certificate-based authentication and disable interactive logins completely. In this way, a user or a machine that needs to access a remote system via SSH simply has to have its own public key registered into the target machine, that in return is authorized the access without a login. The certificate registration only has to be done once, and after this the access is automatic and seamless. Key distribution can also be automated.

If a Linux server has only certificate-based authentication enabled, when a user tries to login with username and password he receives an error, and the only way it can login is if the local SSH certificate is already loaded into the list of Authorized Keys of the target server that he want to connect to. When configuring a new Veeam Backup Job against the same Linux server, also Veeam Backup & Replication V8 needs to have the same key in place. RSA keys are created with a private/public component: usually you end up with two files, id_rsa for the private key and id_rsa.pub for the public key. The public part needs to be saved beforehand into the authorized_keys file of the SSH server of the Linux machine that you want to index. The private key will be instead used during the Veeam backup job configuration. By the way, in the Veeam installation folder there is PuttyGen to help you create the needed keys for the Veeam backup server. Supported SSH keys formats additionally include OpenSSH RSA, OpenSSH DSA, OpenSSL PEM, Open SSL PKCS#8 and SSH.com.

During the Backup wizard, at the Guest Processing step, once guest file system indexing is enabled (linux indexing is by the way another new feature of version 8), the new wizard allows now to configure a public key:

Configure a Linux public key for backups

In the new wizard, you will have to define the user that your key is mapped to (usually is root) and point to the private key you have previously generated:

Configure access via the private key

If you are using a sudo system (like Debian or Ubuntu) you can also configure it during the wizard. Once the key is loaded, you can immediately testing it using the “Test Now” button:

Test the linux private key

This part of the wizard is really helpful since it also tests the required components that need to be installed in order for the guest file system indexing to work. In my case, I installed my CentOS using the minimal install, and by default it does not have mlocate. The other two required components are gzip and tar. Once the needed software are installed, the test completes successfully and the job configuration can be completed. It’s also important to note that you cannot use networkless connections via VMware VIX libraries in this scenario, Veeam server should be able to connect to the target Linux machine via SSH over the network.

During the backup job, you will see the new Linux indexing in action, using the saved private key:

Veeam indexing a Linux VM

In the Job Statistics, you can clearly see the overall process: first Veeam connects to the Linux VM via SSH protocol, using the private key to login. It then uses mlocate to index the file system, and at the end of the job it uses tar and gzip (the other two required binaries) to create the index file. Finally, the index is published to the Veeam Catalog so a user can search for files during restores operations.

I am sure that if you are into Linux like myself, you will absolute love Linux integration enhancements in v8. But we are just starting here! Look forward to the next gem feature in a week.