Updating collective-wide remote authentication keys

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

• You can update the RSA key pair for a single controller.
  1. Stop the controller and all members.
  2. To regenerate keys, remove the $WLP_USER_DIR/servers/collective_controller_name/resources/security/ssh directory.

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

     If you 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.
  Important: When you update the common RSA key pair for a replica, you can have only one controller started during the update process. To allow the start and activation of just one controller, you must remove all other controllers from the active replica set. You can remove these controllers by issuing the removeReplica command for each replica in the active replica set. After you upgrade the RSA key pair, you 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. See Backing up and restoring a Liberty collective.

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

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

     If you 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 you 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.