December 17, 2014 at 09:54Using Veeam Backup for Linux Virtual Machines: Certificate Authentication
- Tutorial
With the release of Veeam Backup & Replication v8, users began to carefully study the new functionality of the product. And since “there is no companion for the taste and color,” everyone finds features that are sweet to the heart for themselves, and these can be very modest, “but very useful gifts,” that is, new options that do not immediately rush into eyes, but on which the developers worked hard. So the “magnificent 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.
Guest file system indexing is required in order to provide the user with a convenient search and quick recovery of necessary files. In particular, Veeam Backup & Replication 8.0 also supports this functionality for Linux virtual machines by providing a convenient Veeam Backup Enterprise Manager web interface:
Veeam performs the corresponding operations using the runtime component, which runs on the guest OS of the virtual machine when the job starts Reserve copy. This component coordinates the processes during indexing (more about them later), and upon completion of the task it stops working. For the runtime-component to work on the guest OS, authentication is required, 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 .
Those who worked with Linux infrastructures are probably aware of the fact that rarely anyone logs on to a Linux server by entering a username and password. There are several reasons for this, among them, in particular, the lack of centralized account management. Yes, someone uses Microsoft Active Directory through Kerberos, someone uses other methods, but this is by no means 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 passwords at least: everyone knows that for security reasons, passwords of sufficient complexity should be used and regularly changed. 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 security is being reduced. We also remember that in addition to human-computer communication, there is also computer-to-computer communication, and in order to ensure communication between servers, you should store passwords where applications and scripts would have access to them - and it is very desirable in some it is protected, not in text format.
Because of all this, Linux system administrators often use a certificate authentication method, completely disabling the ability to log in with a username and password. The idea is for the user (or server) to use a certificate registered on that remote machine to access the remote machine via SSH - this allows authorization without having to enter a username / password.
This certificate needs to be registered only once, after which access will be granted automatically. Certificate issuance can also be automated.
If authentication using a certificate is allowed on the Linux server, then when you try to log in with the 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 loaded into the list of authorized keys ( authorized_keys ) on the server where you want to log in. When setting up a backup job in Veeam Backup & Replication 8.0 that includes such a Linux server , you will need to specify the corresponding private key.
So, first you 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 PuTTY Private Key (PPK) 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 Task Setup Wizard for Linux VMs, we reach the Guest Processing step., enable the option of indexing the guest OS; then in the section for setting access settings, click Add and out of the three methods presented in the list, select Linux public key :
In the dialog that opens, you need to specify which username will be mapped to our key (for example, root ), and specify the path to the private key that you created before. If a passphrase was used when creating the key, enter it too.
After you have specified the key, you can check whether it will work during authentication - for this, after returning to the Guest Processing step, click Test Now and observe the process:
This button is really useful because during key verification, the presence of all components necessary for indexing the guest OS is checked at the same time. So, in the example above, CentOS was used in the minimal configuration, which by default does not include mlocate , whose absence was reported by an error in the session. There are two more utilities needed - gzip and tar .
Actually, the main work is performed by mlocate , which conducts an effective search for files using not the file system, but the index database, and Veeam uses the SSH connection to “give directions” to this utility (start, update the database using updatedb, etc.). (In this scenario, it will not be possible to use the connection via VMware VIX - this functionality is planned for implementation in the future, and in the current version the backup server needs access to Linux VMs via the network via SSH.)
Note that, as ordinary users, there may not be enough access rights files and execution of commands (in particular, the index database is closed for reading by ordinary users), it is recommended that you either specify the root user in the Credentials dialog or enable the Elevate account to root option . Thus, mlocate will return the files found by the index database and metadata (including paths, the time the index was last updated, etc.), and tar
and gzip respectively put all this into one file and gently pack it.
After all the necessary components are installed and the authentication test is successfully passed, you can proceed to the final steps of the setup wizard. And we remember, of course, that the specified settings will be applied to all machines included in the task - unless you specify otherwise for the selected machine (for example, individual settings for access to the guest OS can be entered by clicking the Credentials button at the corresponding step of the wizard).
During the backup task, the statistics window will display detailed information about the progress of indexing Linux OS using a private key:
The screenshot shows the steps of the process (marked with arrows, from top to bottom):
I hope the new Linux virtual machine options come in handy for 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 Linux VM
Guest file system indexing is required in order to provide the user with a convenient search and quick recovery of necessary files. In particular, Veeam Backup & Replication 8.0 also supports this functionality for Linux virtual machines by providing a convenient Veeam Backup Enterprise Manager web interface:
Veeam performs the corresponding operations using the runtime component, which runs on the guest OS of the virtual machine when the job starts Reserve copy. This component coordinates the processes during indexing (more about them later), and upon completion of the task it stops working. For the runtime-component to work on the guest OS, authentication is required, 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 .
Why we decided to support Linux Public Key authentication
Those who worked with Linux infrastructures are probably aware of the fact that rarely anyone logs on to a Linux server by entering a username and password. There are several reasons for this, among them, in particular, the lack of centralized account management. Yes, someone uses Microsoft Active Directory through Kerberos, someone uses other methods, but this is by no means 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 passwords at least: everyone knows that for security reasons, passwords of sufficient complexity should be used and regularly changed. 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 security is being reduced. We also remember that in addition to human-computer communication, there is also computer-to-computer communication, and in order to ensure communication between servers, you should store passwords where applications and scripts would have access to them - and it is very desirable in some it is protected, not in text format.
Because of all this, Linux system administrators often use a certificate authentication method, completely disabling the ability to log in with a username and password. The idea is for the user (or server) to use a certificate registered on that remote machine to access the remote machine via SSH - this allows authorization without having to enter a username / password.
This certificate needs to be registered only once, after which access will be granted automatically. Certificate issuance can also be automated.
If authentication using a certificate is allowed on the Linux server, then when you try to log in with the 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 loaded into the list of authorized keys ( authorized_keys ) on the server where you want to log in. When setting up a backup job in Veeam Backup & Replication 8.0 that includes such a Linux server , you will need to specify the corresponding private key.
How it works in Veeam Backup & Replication v8
So, first you create a pair of RSA keys, and you get two files:
- id_rsa - private key, we save it on the backup server. The path to this key will need to be specified when configuring the backup job.
- id_rsa.pub is the public key, it must be saved in the authorized_keys file of that 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 PuTTY Private Key (PPK) 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 Task Setup Wizard for Linux VMs, we reach the Guest Processing step., enable the option of indexing the guest OS; then in the section for setting access settings, click Add and out of the three methods presented in the list, select Linux public key :
In the dialog that opens, you need to specify which username will be mapped to our key (for example, root ), and specify the path to the private key that you created before. If a passphrase was used when creating the key, enter it too.
After you have specified the key, you can check whether it will work during authentication - for this, after returning to the Guest Processing step, click Test Now and observe the process:
This button is really useful because during key verification, the presence of all components necessary for indexing the guest OS is checked at the same time. So, in the example above, CentOS was used in the minimal configuration, which by default does not include mlocate , whose absence was reported by an error in the session. There are two more utilities needed - gzip and tar .
Actually, the main work is performed by mlocate , which conducts an effective search for files using not the file system, but the index database, and Veeam uses the SSH connection to “give directions” to this utility (start, update the database using updatedb, etc.). (In this scenario, it will not be possible to use the connection via VMware VIX - this functionality is planned for implementation in the future, and in the current version the backup server needs access to Linux VMs via the network via SSH.)
Note that, as ordinary users, there may not be enough access rights files and execution of commands (in particular, the index database is closed for reading by ordinary users), it is recommended that you either specify the root user in the Credentials dialog or enable the Elevate account to root option . Thus, mlocate will return the files found by the index database and metadata (including paths, the time the index was last updated, etc.), and tar
and gzip respectively put all this into one file and gently pack it.
After all the necessary components are installed and the authentication test is successfully passed, you can proceed to the final steps of the setup wizard. And we remember, of course, that the specified settings will be applied to all machines included in the task - unless you specify otherwise for the selected machine (for example, individual settings for access to the guest OS can be entered by clicking the Credentials button at the corresponding step of the wizard).
During the backup task, the statistics window will display detailed information about the progress of indexing Linux OS using a private key:
The screenshot shows the steps of the process (marked with arrows, from top to bottom):
- Veeam connects to Linux VMs via SSH using a private key for login.
- Then, the guest file system is indexed using mlocate .
- After that , a compact index file GuestIndexData.tar.gz is created using tar and gzip .
- At the end of the work, the index file is published in the VBRCatalog directory - so that users can search for files to recover. (You can read more about the catalog here .)
I hope the new Linux virtual machine options come in handy for you or your colleagues. However, this is only the first of 8 stories, to be continued.