SSH For CyberArk: Complete Guide

SSH is not just a protocol you interact with when connecting to Linux boxes. In CyberArk PAM both Self-Hosted and Privilege Cloud, SSH is woven deeply into nearly every component: the Vault stores SSH keys as first-class privileged credentials, the CPM rotates and reconciles them, the PSM on Windows uses SSH through a plugin engine, and the PSMP is an SSH proxy in every meaningful sense. If you do not understand SSH at a protocol and configuration level, you will consistently hit walls you cannot diagnose or design around. This guide covers everything.

SSH Fundamentals (For PAM Context)

SSH (Secure Shell) operates on port 22 by default and provides encrypted communication between a client and a server. Every SSH connection involves two distinct key concerns that people frequently confuse: host authentication (proving the server is who it claims to be) and user authentication (proving the user is who they claim to be). CyberArk touches both, and they must be understood separately.

How SSH Authentication Works

When an SSH client connects to a server, the server presents its host key (a public key). The client checks this against its known_hosts file or cache. If it matches, the client trusts it is talking to the right machine. If it does not match, a warning fires. This is the Man-in-the-Middle protection built into the protocol.

Then, user authentication begins. OpenSSH supports several mechanisms, and CyberArk interacts with most of them:

• Password authentication: Client sends the password over the encrypted channel. Most Linux platforms managed by CPM use this.

• Public key authentication: Client proves possession of a private key. The server checks the corresponding public key in ~/.ssh/authorized_keys. This is what SSH key lifecycle management in CyberArk is all about.

• Keyboard-interactive: Server sends prompts, client responds. Used for MFA flows through PSMP.

• GSSAPI/Kerberos: Used in some enterprise environments; PSMP supports this in specific configurations.

Key Pair Concepts

An SSH key pair consists of:

• A private key: Never leaves the owner. In CyberArk's model, the private key is what gets stored in the Vault for managed accounts.

• A public key: Distributed to target systems and placed in ~/.ssh/authorized_keys. CyberArk's CPM updates this file during rotation.

The most common key algorithms you will encounter are RSA (2048 or 4096 bit, widely supported), ECDSA (256/384/521 bit, faster), and Ed25519 (modern, very strong, compact). CyberArk's SSH Key Manager supports RSA and ECDSA generation natively. Ed25519 support depends on the CPM version and platform plugin. When in doubt, RSA 4096 remains the safest choice for broad compatibility across older target devices.

The Digital Vault and SSH Keys

The Vault is where the private SSH keys for managed accounts live. Understanding this is foundational before touching PSMP or CPM configuration.

What the Vault Actually Stores

When you onboard a Unix account that authenticates via SSH key, the private key is stored as the credential in the Vault safe, not a password. The public key is deployed to the target machine's authorized_keys. The Vault treats an SSH key like any other secret: it is encrypted at rest, access-controlled by Safe permissions, and subject to dual control, one-time password, and audit like any password account.

The account object in the Vault carries several SSH-specific properties. The most important are:

• SSHKey: the private key content itself

• SSHKeyFingerprint: the fingerprint of the key pair, used for group correlation when one key authenticates to multiple targets

• SSHKeyGroupName: when the same private key is shared across multiple target accounts (e.g., one key that SSH's to 30 servers), this groups them for coordinated rotation

Key Groups and Why They Matter

This is a concept that catches many engineers off guard. In real environments, a single SSH private key is often authorized on many servers (think a shared service account). If CPM rotates the key on one account, the public key changes on that target, but all the other servers still have the old public key. The connection breaks everywhere else.

CyberArk solves this through SSH key groups. All accounts sharing the same private key are grouped. During rotation, CPM updates the authorized_keys on every target in the group simultaneously before the old key is retired. The fingerprint property is what links members of a group — accounts with the same fingerprint belong together. When you are onboarding SSH key accounts in bulk, adding the Fingerprint column to the Pending Accounts list lets you visually identify which accounts share a key and group them correctly before onboarding.

Vault Server Keys (Not SSH Keys)

Separate from stored credentials, the Vault itself uses an internal server key to encrypt the data it stores. This is not an SSH key in the protocol sense, it is the Vault's own encryption key. Its path is defined in DBParm.ini. CyberArk strongly recommends removing this key from the Vault filesystem and storing it on an HSM or in a physically secured location. This has nothing to do with SSH protocol but architects are often asked about "SSH keys in the Vault" and the Vault's own encryption keys in the same breath — they are completely different things.

CPM and SSH Key Management

The Central Policy Manager is the engine that manages the lifecycle of SSH keys. On Windows-based CPM (Self-Hosted), it uses a PuTTY/Plink-based plugin. On the Privilege Cloud CPM, it uses a built-in Rebex or FIPS-mode SSH library.

Platforms for SSH Key Accounts

The platform you assign to an account determines how CPM manages it. For SSH key accounts, the relevant platforms are:

• Unix via SSH Keys: The default platform for accounts that authenticate with an SSH key. CPM generates a new key pair, pushes the public key to authorized_keys, and stores the private key in the Vault.

• UnixSSH: For Unix accounts that authenticate with a password over SSH. CPM connects via SSH with a password credential, then changes the password.

• Unix Loosely Connected Devices variants: For endpoints where the CPM cannot maintain a persistent connection for reconcile operations.

On the Unix via SSH Keys platform, the key settings are under Automatic Password Management > Generate Key. Here you define the key algorithm, key size, and whether the CPM is responsible for generating new key pairs or just storing externally generated ones.

How CPM Rotates SSH Keys

Rotation for SSH key accounts works differently from password rotation. The CPM does not simply change a value on the target and store it, it must coordinate the key pair across both the Vault (private key) and every authorized_keys file (public key) in a transaction-like sequence:

1. CPM generates a new RSA (or ECDSA) key pair locally.

2. CPM connects to the target using the current private key stored in the Vault.

3. CPM appends the new public key to ~/.ssh/authorized_keys on the target (both keys are now valid).

4. CPM stores the new private key in the Vault.

5. CPM removes the old public key from authorized_keys, completing the rotation.

If the process fails midway, the reconcile account kicks in. This is why having a properly configured reconcile account is non-negotiable for SSH key platforms. The reconcile account typically has sudo access or is root, so it can write to another user's authorized_keys.

CPM Host Key Trust (The PuTTY Registry Issue)

On Self-Hosted CPM running on Windows, PuTTY/Plink is used for SSH connections to Unix targets. PuTTY maintains its own known-hosts cache in the Windows registry:

HKEY_USERS\.Default\Software\SimonTatham\PuTTY\SshHostKeys

If CPM runs as the Local System account (which it does by default), host key fingerprints are stored under HKEY_USERS\.Default. If the CPM service runs under a named service account, they are stored under HKEY_CURRENT_USER for that account.

When a target server is rebuilt and its SSH host key changes, CPM connections will fail silently, the reconcile will fail with an error that looks like authentication failure, but is actually a host key mismatch. The fix is to delete the stale registry entry for that IP so PuTTY prompts for re-acceptance on the next connection. This is one of the most common operational issues CPM teams encounter.

The platform-level fix for this is configuring the SSH plugin parameters:

The OverrideOnInvalidKeyInCache parameter is supported from TPC version 14.4 onward and is the clean way to handle a key rotation event without opening a change window to manually clear registry entries.

ExpectConfiguration.ini (Privilege Cloud CPM)

On Privilege Cloud, the CPM does not use PuTTY. It uses an internal SSH library. You can influence the SSH cipher suite behavior by creating a file called ExpectConfiguration.ini in the CPM bin folder:

• Default mode: Uses the most commonly supported cipher suites via the Rebex library.

• Restricted mode: FIPS-compliant cipher suites only; limited to RSA key type.

If your environment has FIPS compliance requirements, you must set Restricted mode. Be aware this limits key algorithm flexibility — Ed25519 will not work in Restricted mode.

PSM for Windows (PSM-SSH Connection Component)

PSM on Windows is primarily an RDP-based session proxy, but it supports SSH connections to Unix targets through the PSM-SSH connection component. This component launches a terminal session inside an RDP session that is recorded. It is not a true SSH proxy, the PSM server is the actual SSH client, connecting outbound to the target.

How PSM-SSH Works

When a user clicks Connect in PVWA for a Unix account with PSM-SSH as the connection component, the PVWA launches an RDP session to the PSM server. Inside that session, the PSM opens a terminal (typically PuTTY running inside the PSM hardened desktop) that SSH's directly from the PSM server to the target. The full session is recorded.

Host Key Trust on PSM Servers

Because the PSM server is the SSH client, it must have the target's host key trusted. PSM for Windows uses a controlled SSH host key verification mechanism configured in the platform's PVConfiguration.xml plugin parameters. The StrictHostKeyChecking parameter controls behavior:

accept-new is the recommended production setting for most environments. It protects against MITM (rejects changed keys) but does not require manual pre-seeding of every target's host key before the first connection. yes is the most secure and is used when PSM administrators manually seed known hosts before going live. no is only appropriate for testing environments.

PSMP: The SSH Proxy Architecture

PSM for SSH (PSMP) is the most SSH-intensive component in the entire CyberArk stack. It is a Linux server that acts as an SSH proxy. Users SSH to the PSMP server, and the PSMP connects outbound to the target on behalf of the user. Unlike PSM for Windows, there is no RDP involved, the entire flow is native SSH.

PSMP Architecture Overview

The flow for a PSMP-mediated connection:

1. User's SSH client connects to PSMP server (port 22 or a custom port).

2. PSMP authenticates the user against the Vault (using password or SSH key).

3. PSMP authenticates the user's request against CyberArk policy (platform, safe permissions, dual control if required).

4. PSMP retrieves the target account credential from the Vault.

5. PSMP establishes a new SSH session from itself to the target system using the retrieved credential.

6. PSMP transparently proxies the session, recording it end-to-end.

From the network perspective, PSMP needs inbound SSH from users, outbound SSH to target machines, and outbound communication to the Vault (port 1858 by default for Self-Hosted, HTTPS/443 for Privilege Cloud).

PSMP Deployment Modes: Integrated vs. CyberArk SSHD

This is the most consequential architectural decision for PSMP. The InstallCyberArkSSHD parameter in the PSMP installation parameters file controls whether PSMP installs its own dedicated SSHD service or integrates with the OS's existing OpenSSH daemon.

CyberArk SSHD mode (default, InstallCyberArkSSHD=Yes):

PSMP installs a second SSHD process that runs on a separate port (typically 22 for CyberArk SSHD, with the original OpenSSH SSHD moved to another port like 2222). All privileged proxy connections go through the CyberArk SSHD. The OS's native SSHD remains for administrative access to the PSMP server itself. This is cleaner from a separation-of-concerns standpoint.

Integrated mode (InstallCyberArkSSHD=No):

PSMP integrates into the existing OpenSSH daemon via PAM modules. The files it modifies:

• /etc/pam.d/sshd: PSMP's authentication entry point is injected here.

• /etc/nsswitch.conf: A new NSS module is added so PSMP can resolve its own user naming conventions.

• /etc/pam.d/password-auth: Aligned with PSMP's authentication requirements.

• /etc/ssh/sshd_config: UsePAM yes and ChallengeResponseAuthentication yes are enforced.

Integrated mode is preferred in environments where opening multiple ports or running multiple SSHD processes is not permitted. The trade-off is that changes to sshd_config must be made carefully, if hardening scripts or configuration management tools (Ansible, Chef) later overwrite these settings, PSMP will silently break.

In Integrated mode, ChallengeResponseAuthentication yes is mandatory because keyboard-interactive multi-prompt flows (used for MFA caching and the multi-component authentication flow) depend on it. If this gets set to no by a hardening script, users will see authentication failures that are extremely difficult to diagnose.

PSMP SSH Daemon Hardening

Post-installation, the PSMP server is automatically hardened on RHEL platforms. Key aspects of this hardening include:

• SFTP subsystems (sftp internal-sftp and /usr/libexec/openssh/sftp-server) are disabled by default. If you need SFTP file transfers through PSMP, you must explicitly re-enable the SFTP subsystem after hardening.

• SELinux is recommended to be enabled. CyberArk provides SELinux policies for PSMP.

• The PSMP installation creates a dedicated service user (PSMConnect and PSMAdminConnect) that are locked-down OS accounts used internally for the proxy session. These accounts have no real shell.

Never allow your standard OS hardening runbooks to run against a PSMP server without PSMP-aware exemptions. A generic CIS or DISA STIG hardening script will break PSMP in multiple ways, particularly around PAM configuration and SSHD settings.

The PSMP Connection String

This is what users actually type at the command line to connect through PSMP:

ssh <vaultuser>@<targetuser>@<targetaddress>@<psmp-hostname>

For example:

ssh user@root@linuxserver01.domain.com@psmp.domain.com

Breaking this down:

• user is the CyberArk Vault user (authenticated against the Vault).

• root is the target account stored in the Vault (the credential CyberArk retrieves).

• linuxserver01.domain.com is the target machine address.

• psmp.domain.com is the PSMP proxy server.

The @ delimiter is the default but it is configurable. In environments where usernames or hostnames themselves contain @ symbols (common with email-format usernames), you can change the delimiter in the PSMP configuration to a different character.

To simplify this for users who dislike typing the full string, the SSH client-side ~/.ssh/config file can be leveraged:

Host linuxserver01 HostName psmp.domain.com User user@root@linuxserver01.domain.com IdentityFile ~/.ssh/id_rsa

After this configuration, the user simply types ssh linuxserver01 and the SSH client handles constructing the correct connection to PSMP.

PSMP User Authentication Methods

PSMP supports multiple methods for the user to authenticate to the Vault before being proxied to the target:

Password authentication: The user provides their Vault/LDAP password at the keyboard-interactive prompt. Most common in initial deployments.

SSH key authentication (Vault SSO): The user authenticates to PSMP using their personal SSH private key. The corresponding public key must be stored against their Vault user account, either in the Vault itself or retrieved from the LDAP directory. If the key matches, the Vault authenticates the user without a password prompt. The connection command looks like:

ssh -i ~/.ssh/id_rsa user@root@target.server.com@psmp.domain.com

This is sometimes called Privileged Single Sign-On (PSSO) in CyberArk's documentation. From an architectural standpoint, this is the most seamless user experience — the user has no passwords to type, and the private key acts as their identity proof. However, it requires that public keys be properly registered in the Vault or LDAP for every user who needs this flow.

X.509 certificate authentication: PSMP can authenticate users who present an X.509 certificate in PEM format rather than a traditional SSH key. The certificate must be signed by a CA that PSMP trusts, must not be expired, and must not be revoked. CA certificates must be present in the certificate store folder (default /etc/pki/ca-trust) in rehashed form. CRL files go in /etc/pki/tls/crl. This is the most enterprise-grade option and is used in environments that have a PKI infrastructure and want CAC/smart card-like authentication for SSH sessions.

RADIUS/MFA: PSMP supports RADIUS for MFA. When configured, after the user provides their Vault credentials, a RADIUS challenge fires (sending a push notification, OTP, etc.). Critically, in Integrated mode, RADIUS challenge-response is supported even when RADIUS is configured for challenge-response type. The MFA caching feature (configured under PVWA Administration > Options > Privileged Session Management > General Settings > Server Settings > SSH Proxy Settings) allows a user to receive an MFA challenge once per session cache window rather than for every single PSMP connection.

Managing User Public SSH Keys in the Vault

When users authenticate to PSMP using SSH keys (PSSO), their public keys must be stored somewhere PSMP can retrieve them. There are two options:

Vault-managed keys: An administrator uploads the user's public key directly to the Vault user account via PVWA. This is the simpler model but requires manual key management for every user.

LDAP-managed keys: The public key is stored as an attribute on the user's LDAP/AD object (typically the sshPublicKey attribute in OpenLDAP or a custom AD attribute). PSMP retrieves the key from LDAP at authentication time. This is the enterprise-scale approach users manage their own keys through the directory, and PSMP trusts the directory's answer.

Both models support multiple keys per user. If any one of the stored public keys matches the private key the user presents, authentication succeeds. This is important for key rotation — during a user's key rotation, they can have both the old and new public key registered, so there is no authentication blackout window.

PSMP Host Key Verification for Target Machines

Just as CPM must trust target server host keys, PSMP must also trust the host keys of every target it proxies connections to. PSMP maintains its own SSH host key cache.

The administrator controls this behavior through the PSMP server configuration. The most secure option is to require an administrator to manually add target host keys to the PSMP cache before those targets can be used. This prevents any user from connecting to an unknown or potentially spoofed target through the proxy.

When a target server is rebuilt, its host key changes. The administrator must:

1. Log in to the PSMP server.

2. Remove the stale host key from the PSMP cache.

3. Add the new host key.

If this is not done, all PSMP connections to that target will fail with what appears to be a connection error. This is a very common operational issue in environments where Linux servers are frequently rebuilt or replaced.

PSMP App User and Credentials File

During PSMP installation, a Vault user is automatically created to allow PSMP to authenticate to the Vault and retrieve target credentials. In Privilege Cloud, this user is called PSMPApp_<hostname>. A credentials file (vault.cred or equivalent) is created on the PSMP server. This credentials file is bound to the hostname of the PSMP server, it will only work from that specific machine. This replaces the older IP restriction model and prevents credential file theft from enabling connections from unauthorized machines.

In Self-Hosted environments, the equivalent is the PSMPApp Vault user, and the credential binding is done via the Vault's IP restriction mechanism or the credentials file hostname binding. Either way, if you clone a PSMP VM or change its hostname without regenerating credentials, PSMP will fail to authenticate to the Vault, and all proxy connections will drop.

Putting It All Together: Component-by-Component SSH Summary

Common Operational Issues and How to Diagnose Them

PSMP connections failing after target server rebuild: The target's SSH host key has changed. Clear the stale entry from the PSMP server's known hosts cache and allow the new key to be accepted.

CPM failing to verify/reconcile SSH key accounts: Check the PuTTY registry host key cache on the CPM Windows server. If the target was rebuilt, the registry entry for that IP is stale. Delete it so Plink re-accepts the new key on the next connection. On Privilege Cloud CPM, review the OverrideOnInvalidKeyInCache platform parameter.

PSSO (SSH key login to PSMP) not working: Verify that the user's public key is either in their Vault user account or in LDAP in a format PSMP can retrieve. Verify the key algorithm is supported (RSA and ECDSA yes; Ed25519 depends on version). Check that Integrated mode has ChallengeResponseAuthentication yes in sshd_config.

SFTP through PSMP not working: SFTP is disabled during PSMP hardening. If your environment needs SFTP session proxying, you must explicitly re-enable the SFTP subsystem in sshd_config after the hardening step.

SSH key group accounts breaking during rotation: Accounts that share a private key must be properly grouped via the SSHKeyGroupName property. If any account in the group was onboarded without being linked to the group, CPM will rotate the key for the grouped accounts but leave the standalone account with the old public key, breaking logins from that target.

MFA prompts firing on every PSMP connection: MFA caching is not configured. Enable it under PVWA > Administration > Options > Privileged Session Management > General Settings > Server Settings > SSH Proxy Settings > MFA Caching Settings. Set an appropriate cache window (e.g., 8 hours) aligned with your session policy.

Key Design Principles for Architects

When designing an SSH key management and PSMP architecture, the decisions you make during design will determine years of operational stability:

• Always use SSH key authentication (PSSO) for PSMP where possible. Password-based Vault authentication through PSMP creates a harder user experience and does not scale well when users have dozens of PSMP connections to manage per day.

• Deploy PSMP in HA pairs (two servers minimum). PSMP servers carry zero session state — a user can connect to either node with no difference in experience. Put an L4 load balancer or DNS round-robin in front of them.

• In Integrated mode, protect sshd_config and the PAM files from being overwritten by configuration management. Add exceptions in Ansible/Chef/Puppet playbooks before they run against PSMP nodes.

• Pre-seed PSMP host key caches during onboarding of new Linux estates. Build a runbook that adds target host keys to the PSMP cache as part of server provisioning so users never hit a host key trust failure.

• Plan the authorized_keys ownership model before onboarding SSH key accounts. CPM needs write access to the target account's authorized_keys. If the account is root, this is trivial. If it is a service account, verify the permissions are in place and that SSHD on the target accepts keys from that account's .ssh directory.

• Test the full rotation chain (verify → rotate → reconcile) on one account in a non-production environment before enabling automatic CPM management for SSH key accounts at scale. A misconfigured reconcile account will lock accounts out silently.

Where to Go Next: SSH Beyond CyberArk

SSH as a protocol is one of the most widely used building blocks in infrastructure and security, and it is significantly broader than the subset CyberArk needs to manage. The more you understand SSH itself, the easier it becomes to design, harden, and troubleshoot CyberArk PAM implementations around it especially if you are designing PAM for a Linux-Focused infrastructure.

If you want to go deeper into SSH beyond what is covered in this guide, start with the core, vendor-neutral sources:

• OpenSSH main site and project documentation (architecture, changelogs, security notes):
  https://www.openssh.com

• A good OS-level OpenSSH guide such as:
  Red Hat OpenSSH chapter (ssh, sshd, key files, authorized_keys, host keys) https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-openssh

On the CyberArk side, using the official documentation https://docs.cyberark.com is the best way forward.

If you treat this guide as the CyberArk-specific layer, and combine it with a solid understanding of OpenSSH from the official manuals and hardening guides above, you will have all the building blocks you need to design, operate, and troubleshoot SSH in CyberArk PAM at an expert level.

If this guide helped you design, fix, or simply better understand SSH in a CyberArk PAM environment and you want to support more deep-dive content like this, you can do that here:
Buy Me A Coffee