Update collective-wide remote authentication keys

We can update the single RSA key pair used for collective-wide SSH for both a single controller and a replica set.

By default, a Liberty collective uses a single, common RSA key pair for authentication between controllers and members. When needed, this key pair can be updated.


Update the RSA key pair for a single controller

  1. Stop the controller and all members.

  2. Regenerate keys

      rm -rf $WLP_USER_DIR/servers/collective_controller_name/resources/security/ssh

    If we use the regenerated keys as an existing SSH key pair, configure them in server.xml of the controller with the private and public SSH key paths.

    If we use SAF key rings, configure the <collectiveHostAuthInfo> element in the server.xml of the controller with the appropriate key ring information.

  3. Start the controller.

    On activation, the controller updates the common public SSH key in the repository.

  4. Start members.

    On connection to the controller, each member receives the new public SSH key and add it to the user's authorized_keys file.


Update the RSA key pair for a replica set

When updating the common RSA key pair for a replica, we can have only one controller started during the update process. To allow the start and activation of just one controller, remove all other controllers from the active replica set by issuing the removeReplica command for each replica in the active replica set. After upgrading the RSA key pair, we can add these replicas back to the active replica set by issuing the addReplica command.

  1. Stop all replicas in the replica set and all members.

  2. Back up the replicas in the replica set.

    Back up the entire replica server directory, of $WLP_USER_DIR/servers/server_name directory and its subdirectories. Or, at minimum, back up the frappe database directory that holds the replica data...

      $WLP_USER_DIR/servers/collective_controller_name/resources/collective/repository/fdb

    We can use the first replica backup for the remaining replicas.

  3. Copy the same SSH key pair to each of replica systems.

    If we use SAF key rings, make sure that the key ring is accessible from each replica system.

  4. Configure the <collectiveHostAuthInfo> element in all replicas with the private and public SSH key paths.

    If we use SAF key rings, configure the <collectiveHostAuthInfo> element in all replicas with the same key ring configuration.

  5. Start one replica.

    The one active replica updates the common public SSH key in the repository. After the replica is running, look for the CWWKX6011I message in the replica messages to see whether the replica synchronized correctly. The message resembles the following one:

      CWWKX6011I: The collective controller is ready, and can accept requests.
      The leader is replicaHost:replicaPort.
      Current active replica set is replicaHost:replicaPort,replicaHost:replicaPort,replicaHost:replicaPort.
      The configured replica set is replicaHost:replicaPort,replicaHost:replicaPort,replicaHost:replicaPort.

  6. After verifying that the replica synchronized, start the other replicas.

    On activation, each replica verifies that its local public SSH key matches the common public SSH key in the repository.

  7. Start members.

    On connection to the replica, each member receives the new public SSH key and adds it to the user's authorized_keys file.


Parent topic: Update a Liberty collective