Passwordless SSH

Proper passwordless SSH setup from ClusterControl node to all nodes (including ClusterControl node) is mandatory. Before performing any operation on the managed node, the node must be accessible via SSH without using a password by using the key-based authentication instead.

ClusterControl uses libssh (a multiplatform C library using SSHv2 protocol) which supports the following public-key algorithms:

• ssh-rsa
• rsa-sha2-512
• rsa-sha2-256
• ssh-dss
• ssh-ed25519
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521

Setting up Passwordless SSH

To set up a passwordless SSH, make sure you generate SSH keys (private and public keys) and copy the public key from the ClusterControl host as the designated user to the target host. Take note that ClusterControl also requires passwordless SSH to itself, so do not forget to set this up as described in the example below.

Most of the sampling tasks for the controller are done locally but there are some tasks that require a working self-passwordless SSH e.g: starting netcat when performing backup (to stream a backup to the other node). There are also various places where ClusterControl performs the execution uniformly regardless of the node’s role or type. Hence, setting this up is compulsory and failing to do so will result in ClusterControl raising an alarm.

To generate an SSH key, use the ssh-keygen command which is available with the OpenSSH-client package. On ClusterControl node:

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts

The above command will generate SSH RSA private and public keys under the user’s home directory, /root/.ssh/. The private key, id_rsa has to be kept secure on the node. The public key, id_rsa.pub should be copied over to all nodes that want to be accessed by ClusterControl passwordlessly.

The next step is to copy the SSH public key to all nodes. You may use the ssh-copy-id command to achieve this if the destination node supports password authentication:

$ whoami
root
$ ls -1 ~/.ssh/id*
/root/.ssh/id_rsa
/root/.ssh/id_rsa.pub
$ ssh-copy-id 192.168.0.10 # specify the root password of 192.168.0.10 if prompted

The command ssh-copy-id will simply copy the public key from the source server and add it into the destination server’s authorized key list, default to ~/.ssh/autohorized_keys of the authenticated SSH user. If password authentication is disabled, then a manual copy is required. On ClusterControl node, copy the content of SSH public key located at ~/.ssh/id_rsa.pub and paste it into ~/.ssh/authorized_keys on all managed nodes (including ClusterControl server).

The following example shows how a root user on the ClusterControl host (192.168.0.10) generates and copies an SSH key to databases hosts (192.168.0.11, 192.168.0.12, 192.168.0.13) and to itself (192.168.0.10):

$ whoami
root
$ ssh-keygen -t rsa # press Enter on all prompts
$ ls -1 ~/.ssh/id*
/root/.ssh/id_rsa
/root/.ssh/id_rsa.pub
$ ssh-copy-id 192.168.0.10 # specify the root password of 192.168.0.10 if prompted
$ ssh-copy-id 192.168.0.11 # specify the root password of 192.168.0.11 if prompted
$ ssh-copy-id 192.168.0.12 # specify the root password of 192.168.0.12 if prompted
$ ssh-copy-id 192.168.0.13 # specify the root password of 192.168.0.13 if prompted

If you are running as a sudo user e.g “sysadmin”, here is an example:

$ whoami
sysadmin
$ ssh-keygen -t rsa # press Enter on all prompts
$ ls -1 ~/.ssh/id*
/home/sysadmin/.ssh/id_rsa
/home/sysadmin/.ssh/id_rsa.pub
$ ssh-copy-id 192.168.0.10 # specify the sysadmin password of 192.168.0.10 if prompted
$ ssh-copy-id 192.168.0.11 # specify the sysadmin password of 192.168.0.11 if prompted
$ ssh-copy-id 192.168.0.12 # specify the sysadmin password of 192.168.0.12 if prompted
$ ssh-copy-id 192.168.0.13 # specify the sysadmin password of 192.168.0.13 if prompted

You should be able to SSH from ClusterControl to the other server(s) without a password:

$ ssh {username}@{server IP address}

For cloud users, you can use the corresponding key pair generated by the cloud provider by uploading it onto the ClusterControl host and specify the physical path when configuring the SSH-related parameters in the ClusterControl UI (deploy a cluster, import nodes, etc). ClusterControl will then use this key to perform tasks that require passwordless SSH and store the path via ssh_identity variable inside CMON configuration file:

ssh_identity=/path/to/keypair/cloud.pem

If you use other public-key algorithms (CMON defaults to RSA), make sure the public key generated on the ClusterControl node is copied and allowed on all managed nodes under ~/.ssh/autohorized_keys. You can use ssh-copy-id command (as shown in the example above), or simply copy the public key to all managed nodes manually.

Sudo password

Sudo with or without a password is possible. If undefined, CMON will escalate to sudoer without a password. When deploying a new or importing an existing cluster into ClusterControl, the user will be asked to specify the sudo password in the deployment dialog. The specified sudo password is then stored inside the CMON configuration file under sudo variable:

sudo="echo 'thesudopassword' | sudo -S 2>/dev/null"

 Encrypted home directory

If the sudo user’s home directory is encrypted, you might be facing the following scenarios:

• First SSH login will require a password, even though you have copied the public key to the remote host’s authorized_keys.
• If you run another SSH session, while the first SSH session is still active, you will be able to authenticate without a password and the key authentication is successful.

Encrypted home directories are not decrypted until the login is successful, and your SSH keys are stored in your home directory. The first SSH connection you make will require a password. While the subsequent connections will no longer need a password since the SSH service is able to read the authorized_keys (inside user’s homedir) in a decrypted environment.

To solve this, you need to follow the instructions on this page, Passwordless SSH in Encrypted Home Directory.