Linux Private Keys (Identity/Pubkey)
You can log on to a Linux server or VM running Linux OS using the Identity/Pubkey authentication method. The Identity/Pubkey authentication method helps protect against malicious applications like keyloggers, strengthens the security level and simplifies launch of automated tasks.
To use the Identity/Pubkey authentication method, you must generate a pair of keys — a public key and private key:
- Public key is stored on Linux servers to which you plan to connect from the backup server. The key is kept in a special authorized_keys file containing a list of public keys.
- Private key is stored on the client machine — backup server. The private key is protected with a passphrase. Even if the private key is intercepted, the eavesdropper will have to provide the passphrase to unlock the key and use it.
For authentication on a Linux server, the client must prove that it has the private key matching the public key stored on the Linux server. To do this, the client generates a cryptogram using the private key and passes this cryptogram to the Linux server. If the client uses the "correct" private key for the cryptogram, the Linux server can easily decrypt the cryptogram with a matching public key.
Veeam Backup & Replication has the following limitations for the Identity/Pubkey authentication method:
- Veeam Backup & Replication does not support keys that are stored as binary data, for example, in a file of DER format.
- Veeam Backup & Replication supports only keys whose passphrase is encrypted with algorithms supported by PuTTY:
- AES (Rijndael): 128-bit, 192-bit and 256-bit CBC or CTR (SSH-2 only)
- Blowfish: 128-bit CBC
- Triple-DES: 168-bit CBC
- The current version of Veeam Backup & Replication supports the DSA and RSA algorithms with the following key formats:
- PKCS8 (RSA only)
If you use VMware VIX/vSphere Web Services, Veeam Backup & Replication does not support usage of public keys for guest processing on Linux guest servers.
To add a credentials record using the Identity/Pubkey authentication method:
- Generate a pair of keys using a key generation utility, for example, ssh-keygen.
- Place the public key on a Linux server. To do this, add the public key to the authorized_keys file in the .ssh/ directory in the home directory on the Linux server.
- Place the private key in some folder on the backup server or in a network shared folder.
- In Veeam Backup & Replication, from the main menu select Manage Credentials.
- Click Add > Linux private key.
- In the Username field, specify a user name for the created credentials record.
- In the Password field, specify the password for the user account. The password is required in all cases except when you use root or a user with enabled NOPASSWD:ALL setting in /etc/sudoers.
- In the Private key field, enter a path to the private key or click Browse to select a private key.
- In the Passphrase field, specify a passphrase for the private key on the backup server. To view the entered passphrase, click and hold the eye icon on the right of the field.
- In the SSH port field, specify a number of the SSH port that you plan to use to connect to a Linux server. By default, port 22 is used.
- If you specify data for a non-root account that does not have root permissions on a Linux server, you can use the Non-root account section to grant sudo rights to this account.
- To provide a non-root user with root account privileges, select the Elevate specified account to root check box.
- To add the user account to sudoers file, select the Add account to the sudoers file automatically check box. In the Root password field, enter the password for the root account.
If you do not enable this option, you will have to manually add the user account to the sudoers file.
- When registering a Linux server, you have an option to failover to using the su command for distros where the sudo command is not available.
To enable the failover, select the Use "su" if "sudo" fails check box and in the Root password field, enter the password for the root account.
- In the Description field, enter a description for the created credentials record. As there can be a number of similar account names, for example, Root, it is recommended that you supply a meaningful unique description for the credentials record so that you can distinguish it in the list. The description is shown in brackets, following the user name.
Cases when root password is required to elevate account rights to root using sudo are no longer supported.