Just in Time access with short-lived SSH certificates

This topic describes how to configure Just in Time (JIT) access in PSM for SSH using short-lived SSH certificates.

Overview

Secure access with SSH in dynamic or large scale environments can be problematic. Managing local accounts credentials and SSH keys for each and every server requires either high levels of automation or a large amount of manual processes, especially when machines are frequently spun-up. Having static SSH keys, shared accounts, and personal accounts leads to a larger number of privileged accounts and standing access on the target, increasing the attack surface and not following the least privilege concept.

Just in Time SSH certificate authentication to targets avoids the need to onboard the accounts to PAM - Self-Hosted, without any need for credentials, public keys or standing access on the target.

An administrator can simply store a single private key in the Vault that acts as a certificate authority (CA) for certificate signing, and the corresponding public SSH key on the target machines. There's no need to generate a private-public key pair for each account and target machine.

End-users use SSH to connect to a target machine through PSM for SSH. After authenticating to CyberArk, CyberArk signs and uses a short-lived SSH certificate to authenticate to the target machine with an isolated and controlled session.

OpenSSH 5.3 or higher must be installed on the target machine.

Following are some use cases:

• Mike is an Information Security Specialist who is a Vault Administrator in his company. Paul is a Linux administrator who manages a group of administrators who oversee the Production servers.
• For Paul's administrators to have secure access to new production servers, Mike generates an SSH key pair that will act as a certificate authority (CA) for the production servers and stores the private key in an account in the Vault. The account is configured as an "SSH certificate" type and does not have a specific address assigned to it, so it can be used for all production servers.
• Mike also grants permissions only for the production administrators to this account.
• Paul has set up a template for the production servers so that each new server is spun-up with the production CA public key as a trusted CA key.
• Now, when a new production server is spun-up, Paul's administrators (for example, John) can instantly SSH to it through PSM for SSH, by specifying the target address and that it is a "production" server: ssh john@root#production@TargetAddress@PSMPAddress
• After authenticating to CyberArk, PSM for SSH will sign an SSH key with the production CA private key so that the target can trust it and use it to authenticate the user to the target.

  PSM for SSH creates the certificate, automatically uses it to authenticate the user to the remote machine, and then discards it. The certificate never reaches the end user's workstation. Although the default TTL for the certificate created by PSM for SSH is five minutes (in the future the TTL will be configurable), the actual time that the certificate is alive is generally a matter of a few seconds. For subsequent connections, PSM for SSH signs and creates a new certificate.

• Mike and Paul can repeat this process for a different set of servers and users. For example, Mike can generate another CA key pair for the "Test" servers. Paul will deploy the "Test" CA public key on the "Test" servers, and Mike will store the "Test" CA private key in an account and a safe that only the "Test" engineers have access to.

Generate the SSH certificate keys

To enable users to use Just in Time SSH certificate authentication to access target machines, generate the private and public CA keys on a secure machine.

1. Run the following command:

   ssh-keygen -f /etc/ssh/{certificate_name}

   Private and public ssh keys pair are generated:

   • {certificate_name} - private CA key
   • {certificate_name}.pub - public CA key

   For example,

   ssh-keygen -f /etc/ssh/production_CA

2. Use the private CA key to create an SSH certificate platform and SSH certificate account. For details, see Configure platforms to support privileged SSO using an SSH certificate.

   The private key is sensitive and must be removed from the machine where it was created after moving it to the SSH certificate account.

3. On each target machine that users will connect to using PSM for SSH, store the CA public key in the /etc/ssh/ folder. For example, store production_CA.pub on the Production servers.

   You can also include the CA public key as part of the template for creating new servers. For example, when you spin up a new Production server, the CA public key will automatically be deployed.

4. Mark the public CA key as globally trusted. Edit the sshd_config file found in /etc/ssh/sshd_config and set TrustedUserCAKeys to /etc/ssh/<public CA key>.pub.

5. Restart the sshd service.

   service sshd restart

6. To set up another group of servers to be accessed by different users, repeat the above process to create a CA key pair and deploy the CA public key on the relevant target servers.

Limitations

JIT access in PSM for SSH using SSH certificates does not support the following:

• Telnet
• CPM rotation for the CA keys - you can manually generate a new set of CA keys and replace the existing private and public CA keys.
• AD Bridge in PSM for SSH

Troubleshooting

If the user connecting via PSM for SSH receives a This session is being recorded message but also receives a Permission denied message, open the /var/log/secure log file and check whether the key has expired. If the key has expired:

1. Verify that the time (clock) of the PSM for SSH machine and the target machine are aligned . This can be verified by running the date command on both servers and comparing the results.

2. Once the clocks are in sync, restart the sshd on the target and re-connect successfully.