Managing SSH access to the PPC CLI

After deployment of the PPC cluster, each user can be granted SSH access to the CLI pod by enrolling their public key. The bootstrap.sh script manages adding, listing, and revoking CLI users.

Adding or revoking a key updates the cluster configuration and applies the CLI key resource in Stage 05 (05_helm_releases). SSH key enrollment grants access to the CLI pod. It does not create a Protegrity CLI application account. After connecting, users still need valid application credentials to sign in to the interactive CLI.

Prerequisites

• The PPC cluster is deployed.

• Run all commands from the deployment directory. To view the available commands and options, run the following command:

  cd deployment
  ./bootstrap.sh --help
  

  The bootstrap.sh script manages adding, listing, and revoking CLI users.

• kubectl is configured with access to the target cluster. The access commands can detect AWS or Azure from the active context; the cloud can also be specified explicitly.

• For clusters using an authenticated private registry, export the registry credentials before running CLI-user commands.

  export TF_VAR_username="<registry-username>"
  export TF_VAR_password="<registry-password>"
  

  These credentials are required because the commands re-apply Stage 05. For more information, refer to Troubleshooting.

• The user’s public key file (.pub) is available. Keep the corresponding private key on the user’s device, do not send it to the cluster administrator, and restrict access to it. On Linux/macOS, use chmod 600 <key-name> if needed. On Windows, restrict the file’s ACL to the user.

• On secured clusters, use a supported key type. Standard clusters do not apply these secured-cluster key restrictions:

The ECDSA command above generates a P-256 key. The key type is checked against the CLI pod’s SSH policy before enrollment.

Adding CLI user

To add a user with SSH access to the PPC CLI, perform the following steps:

1. Generate a key pair using either a 4096-bit RSA key or an ECDSA P-256 key.

   ssh-keygen -t rsa -b 4096 -f <key-name> -N ""   # For RSA, 2048 bits or more
   
   ssh-keygen -t ecdsa -b 256 -f <key-name> -N ""  # For ECDSA P-256, P-384, or P-521
   

   <key-name> is the private-key filename. The public key is written to <key-name>.pub. Use only the .pub file for enrollment. Keep the private key local and appropriately permissioned.

2. Enroll the public key of the required user.

   ./bootstrap.sh --add-cli-user --user <user-name> --public-key-file <key-name>.pub
   

   To select the cloud explicitly, add --cloud aws or --cloud azure. By default, the script detects the cloud from the active kubectl context.

3. Confirm that the command reports the public key as validated and authorized. The script applies Stage 05 and verifies the key in the user-svc-keys secret. The apply targets only the CLI key resource. Resource-targeting warnings in the command output are expected.

   Expected result: Stage 05 completes, and the enrolled user’s public key is present in user-svc-keys. This confirms enrollment, but does not by itself prove that SSH authentication works.

4. Verify SSH access by connecting to the CLI host with the matching private key:

   ssh -o IdentitiesOnly=yes -i <key-name> -p 22 ptyitusr@<FQDN>
   

   For example: ssh -o IdentitiesOnly=yes -i user.key -p 22 ptyitusr@user.example.com.

   Expected result: SSH authenticates with the enrolled key and opens the CLI session. Then provide the user’s Protegrity CLI username and password when prompted. This application sign-in is separate from SSH authentication.

Each username maps to one public key. When rotating a key for an existing username, verify the resulting fingerprint with --list-cli-user and test SSH using the new private key. Do not assume the previous key was replaced until the list, and login checks confirm it. If the command reports a duplicate-user or key-validation error, refer to Troubleshooting.

To verify multi-user access, enroll two distinct usernames with their own public keys. List both entries, and have each user authenticate with their own private key. After revoking one user, confirm the other user’s fingerprint remains listed and that user’s SSH login still succeeds.

Listing CLI users

To list the enrolled users and their public-key fingerprints, run the following command:

./bootstrap.sh --list-cli-user

Expected result: For every enrolled username, verify the username and the fingerprint match the public key that user supplied. The list contains fingerprints, not private keys. For example, output should identify entries equivalent to:

<user-name>  <public-key-fingerprint>

Revoking a CLI user

To remove a CLI user SSH access to the PPC CLI, run the following command:

./bootstrap.sh --revoke-cli-user --user <user-name>

Specify --cloud aws or --cloud azure to bypass automatic cloud detection. The command applies Stage 05 to revoke the user’s CLI pod SSH access.

Expected result: The command completes successfully and applies the updated CLI key resource. Run --list-cli-user and verify that the revoked username is no longer listed. Then attempt SSH using that user’s previously authorized private key; authentication should be denied. Confirm other enrolled usernames and fingerprints remain listed, and verify another user’s SSH login still succeeds.

The following are illustrative verification checkpoints, exact command messages can vary:

Add:    key validated; Stage 05 applied; key verified in user-svc-keys
List:   <user-name>  <public-key-fingerprint>
Revoke: Stage 05 applied; <revoked-user> absent from --list-cli-user
SSH:    Permission denied (publickey) for the revoked user's key

Dry Run

Append --dry-run to an add or revoke command to preview its changes. The script runs an OpenTofu plan instead of applying the change.

./bootstrap.sh --add-cli-user --user <user-name> --public-key-file <key-name>.pub --dry-run  # add cli user command
./bootstrap.sh --revoke-cli-user --user <user-name> --dry-run                                # revoke cli user command

Expected result: Review the plan and confirm it targets the intended CLI key resource and the intended username or key change. A dry run does not persist changes to terraform.tfvars, update the user-svc-keys secret, authorize a new key, or revoke an existing key. Verify no access state changed by listing users. Do not treat a dry run as proof of successful SSH access or revocation. Run the command again without --dry-run to apply it.

Troubleshooting