Using Veeam Backup for Linux-based Virtual Machines: Certificate Based Authentication
With the release of Veeam Backup & Replication v8, users began to carefully study the new functionality of the product. And since “there is no friend to the taste and color,” everyone finds some nice features for himself personally, and this can be quite modest, “but very useful gifts,” that is, new options that do not immediately rush into eyes, but on which the developers worked hard. This is how the “gorgeous eight” was selected, maybe not very sensational, but very useful features of Veeam Backup & Replication v8. My today's story is about authentication using a certificate when accessing the guest OS of virtual machines running Linux.
Indexing the guest file system is required in order to provide the user with a convenient search and quick recovery of the necessary files. In particular, Veeam Backup & Replication 8.0 supports this functionality for virtual machines running Linux, providing a convenient web interface Veeam Backup Enterprise Manager:
Veeam performs the corresponding operations using a runtime component that runs on the guest OS of the virtual machine when the backup job starts. This component coordinates the processes during indexing (about them a bit later), and upon completion of the task it stops working. The runtime component works on the guest OS and requires authentication, for which Veeam Backup & Replication 8 now also supports the use of a certificate (Linux public key).
For more information on indexing the guest file system, see here and here (in English).
Those who worked with Linux-infrastructures are probably in the know - rarely anyone logs in to the Linux server, entering a username and password. There are several reasons for this, among them, in particular, the lack of centralized account management. Yes, someone is using Microsoft Active Directory through Kerberos, someone is different, but this is not a mass phenomenon, and setting up and managing a large number of accounts in a rather large infrastructure can be a headache for someone responsible for this.
')
Take at least passwords: everyone knows that for security purposes you should use passwords of sufficient complexity and change them regularly. Yes, you can spend half your life on this! Someone decides to simplify the task and use, say, never changing passwords, or simple short passwords. It is clear that life is becoming easier, but safety is reduced. We also remember that in addition to the “human-computer” communication, there is also a “computer-to-computer” communication, and in order to ensure communication between servers, passwords should be stored where applications and scripts would have access to them — while it is highly desirable to This is a protected form and not in text format.
Because of all this, Linux system administrators often use the authentication method using a certificate, completely disabling the ability to log in with the input of a name and password. The idea is for a user (or server) to access a remote machine via SSH with a certificate registered on that remote machine - which allows you to get authorization without having to enter a name \ password.
This certificate must be registered only once, after which access will be granted automatically. The issuance of certificates can also be automated.
If authentication is enabled on the Linux server using a certificate, then when you try to log in with a username and password, the user will see an error message. The only possible login option with these settings is if the local SSH certificate (public key) is uploaded to the list of allowed keys ( authorized_keys ) on the server where you need to log in. When you configure the backup job in Veeam Backup & Replication 8.0, which includes such a Linux server , you will need to specify the corresponding private key.
So, first create a pair of RSA-keys, and you get two files:
By the way, PuTTYGen is present in the Veeam installation directory - it can be used to generate the PuTTY Private Key (PPK) private keys for the Veeam Backup & Replication backup server. The following SSH key formats are supported: OpenSSH RSA, OpenSSH DSA, OpenSSL PEM, Open SSL PKCS # 8, and SSH.com.
More detailed information, as well as a description of working with Credentials Manager - a tool for centralized management of access settings in Veeam Backup & Replication, can be found here (in English).
User access settings can also be entered during the creation of a backup or replication task. In the Backup Job Setup Wizard for Linux VM, we reach the Guest Processing step, enable the index option of the guest OS; then in the section for setting access settings, click Add and from the three methods presented in the list select the Linux public key :
In the dialog that opens, you need to specify what username our key (for example, root ) will be assigned to and specify the path to the private key that you previously created. If the key phrase was used to create the key (passphrase), enter it too.
After you have specified the key, you can check whether it will work during authentication - to do this, after returning to the Guest Processing step, click Test Now and watch the process:
This button is really useful, because When checking a key, it checks at the same time the presence of all components necessary for indexing the guest OS. So, in the example above, CentOS was used in a minimal configuration, where mlocate is not included by default , whose absence was reported by the session error. There are two more utilities needed - gzip and tar .
Actually, the main work is performed by mlocate , which conducts an effective file search using not the file system, but the index database, and Veeam uses an SSH connection to “issue instructions” to this utility (start, update the database using updatedb , etc.) . (In this scenario, the connection via VMware VIX will not succeed - this functionality is planned for future implementation, and in the current version, the backup server needs access to the Linux VM over the network via SSH.)
Note that since ordinary users may not have enough rights to access files and execute commands (in particular, the index database is closed for normal users to read), it is recommended to either specify the root user in the Credentials dialog or enable the Elevate account to root option.
Thus, mlocate will output the files found from the index database and the metadata (including the paths, the time of the last update of the index, etc.), and tar and gzip respectively will add all of this into one file and carefully package it.
After all necessary components are installed and the authentication test is successfully passed, you can proceed to the final steps of the setup wizard. And remember, of course, these settings will be applied to all the machines included in the task - unless you specify otherwise for the selected machine (for example, you can enter individual settings for the guest OS by clicking the Credentials button at the appropriate wizard step).
During the execution of the backup task, the statistics window will display detailed information about the Linux indexing process using the private key:
The screenshot shows the process steps (marked by arrows, top to bottom):
I hope the new options for working with virtual machines running Linux will be useful to you or your colleagues. However, this is only the first of 8 stories, to be continued.
Why do we need access to the guest OS on the Linux VM
Indexing the guest file system is required in order to provide the user with a convenient search and quick recovery of the necessary files. In particular, Veeam Backup & Replication 8.0 supports this functionality for virtual machines running Linux, providing a convenient web interface Veeam Backup Enterprise Manager:
Veeam performs the corresponding operations using a runtime component that runs on the guest OS of the virtual machine when the backup job starts. This component coordinates the processes during indexing (about them a bit later), and upon completion of the task it stops working. The runtime component works on the guest OS and requires authentication, for which Veeam Backup & Replication 8 now also supports the use of a certificate (Linux public key).
For more information on indexing the guest file system, see here and here (in English).
Why we decided to support Linux Public Key authentication
Those who worked with Linux-infrastructures are probably in the know - rarely anyone logs in to the Linux server, entering a username and password. There are several reasons for this, among them, in particular, the lack of centralized account management. Yes, someone is using Microsoft Active Directory through Kerberos, someone is different, but this is not a mass phenomenon, and setting up and managing a large number of accounts in a rather large infrastructure can be a headache for someone responsible for this.
')
Take at least passwords: everyone knows that for security purposes you should use passwords of sufficient complexity and change them regularly. Yes, you can spend half your life on this! Someone decides to simplify the task and use, say, never changing passwords, or simple short passwords. It is clear that life is becoming easier, but safety is reduced. We also remember that in addition to the “human-computer” communication, there is also a “computer-to-computer” communication, and in order to ensure communication between servers, passwords should be stored where applications and scripts would have access to them — while it is highly desirable to This is a protected form and not in text format.
Because of all this, Linux system administrators often use the authentication method using a certificate, completely disabling the ability to log in with the input of a name and password. The idea is for a user (or server) to access a remote machine via SSH with a certificate registered on that remote machine - which allows you to get authorization without having to enter a name \ password.
This certificate must be registered only once, after which access will be granted automatically. The issuance of certificates can also be automated.
If authentication is enabled on the Linux server using a certificate, then when you try to log in with a username and password, the user will see an error message. The only possible login option with these settings is if the local SSH certificate (public key) is uploaded to the list of allowed keys ( authorized_keys ) on the server where you need to log in. When you configure the backup job in Veeam Backup & Replication 8.0, which includes such a Linux server , you will need to specify the corresponding private key.
How it works in Veeam Backup & Replication v8
So, first create a pair of RSA-keys, and you get two files:
- id_rsa is a private key, we save it on the backup server. The path to this key will need to be specified when configuring the backup task.
- id_rsa.pub is the public key, you need to save it to the authorized_keys file of the SSH server (Linux VM) whose guest OS you plan to index.
By the way, PuTTYGen is present in the Veeam installation directory - it can be used to generate the PuTTY Private Key (PPK) private keys for the Veeam Backup & Replication backup server. The following SSH key formats are supported: OpenSSH RSA, OpenSSH DSA, OpenSSL PEM, Open SSL PKCS # 8, and SSH.com.
More detailed information, as well as a description of working with Credentials Manager - a tool for centralized management of access settings in Veeam Backup & Replication, can be found here (in English).
User access settings can also be entered during the creation of a backup or replication task. In the Backup Job Setup Wizard for Linux VM, we reach the Guest Processing step, enable the index option of the guest OS; then in the section for setting access settings, click Add and from the three methods presented in the list select the Linux public key :
In the dialog that opens, you need to specify what username our key (for example, root ) will be assigned to and specify the path to the private key that you previously created. If the key phrase was used to create the key (passphrase), enter it too.
After you have specified the key, you can check whether it will work during authentication - to do this, after returning to the Guest Processing step, click Test Now and watch the process:
This button is really useful, because When checking a key, it checks at the same time the presence of all components necessary for indexing the guest OS. So, in the example above, CentOS was used in a minimal configuration, where mlocate is not included by default , whose absence was reported by the session error. There are two more utilities needed - gzip and tar .
Actually, the main work is performed by mlocate , which conducts an effective file search using not the file system, but the index database, and Veeam uses an SSH connection to “issue instructions” to this utility (start, update the database using updatedb , etc.) . (In this scenario, the connection via VMware VIX will not succeed - this functionality is planned for future implementation, and in the current version, the backup server needs access to the Linux VM over the network via SSH.)
Note that since ordinary users may not have enough rights to access files and execute commands (in particular, the index database is closed for normal users to read), it is recommended to either specify the root user in the Credentials dialog or enable the Elevate account to root option.
Thus, mlocate will output the files found from the index database and the metadata (including the paths, the time of the last update of the index, etc.), and tar and gzip respectively will add all of this into one file and carefully package it.
After all necessary components are installed and the authentication test is successfully passed, you can proceed to the final steps of the setup wizard. And remember, of course, these settings will be applied to all the machines included in the task - unless you specify otherwise for the selected machine (for example, you can enter individual settings for the guest OS by clicking the Credentials button at the appropriate wizard step).
During the execution of the backup task, the statistics window will display detailed information about the Linux indexing process using the private key:
The screenshot shows the process steps (marked by arrows, top to bottom):
- Veeam connects to the Linux VM via SSH, using the private key for the login.
- Then using mlocate indexed guest file system.
- After that, using tar and gzip creates a compact index file GuestIndexData.tar.gz .
- At the end of the work, the index file is published in the VBRC catalog catalog - so that users can search for files to restore. (Read more about the catalog here .)
I hope the new options for working with virtual machines running Linux will be useful to you or your colleagues. However, this is only the first of 8 stories, to be continued.
Additional Information:
Source: https://habr.com/ru/post/245931/
All Articles