Linux For CyberArk: Complete Guide

This guide will cover everything you need to know about Linux as a CyberArk professional. It focuses specifically on how Linux underpins CyberArk PAM Self‑Hosted and Privilege Cloud, and walks through the commands, configuration files, logs, and internal workflows you need to architect, operate, and troubleshoot PSMP, PTA, and SIA end‑to‑end.

Whether you’re a CyberArk architect, engineer, or team lead, the goal is to give you a practical field manual: you’ll see not just which Linux commands and files matter, but also what they do, why they’re important for CyberArk, and how PSMP and SIA SSH connections work internally so you can design robust, auditable access paths.

1. Big picture: Linux in PAM and Privilege Cloud

In CyberArk PAM Self‑Hosted and Privilege Cloud, the main Linux‑based components you care about are PSM for SSH (PSMP), Privileged Threat Analytics (PTA), and the Linux footprint of SIA (connectors, SSH CA integration, logs).

These Linux nodes are security appliances: they run minimal OS images, host PSMP/PTA/connector services, rely on standard Linux primitives (systemd, OpenSSH, journald/syslog, file permissions), and produce logs you must integrate with SIEM and audit tooling.

2. Linux building blocks for CyberArk

2.1 Service management with systemctl

systemctl is the CLI interface to systemd, the init system used on modern RHEL/Rocky/Alma and many other distros.

• systemctl status <service> contacts systemd and shows whether the unit is active, failed, or inactive, the PID, last exit code, and recent log lines; for example, systemctl status psmpsrv tells you if PSMP is running and why it failed if it isn’t.

• systemctl start|stop|restart <service> sends control commands to the service; for PSMP and PTA you restart their services after changing configs (e.g. systemctl restart psmpsrv or systemctl restart appmgr).

• systemctl enable|disable <service> configures whether a service starts at boot, which you typically leave enabled for PSMP/PTA so they survive reboots.

For runbooks, define a standard health‑check pattern: systemctl status, then journalctl -u <service> if status is not active (running).

2.2 Log inspection with journalctl

On systemd systems, logs are stored in the binary journal and accessed via journalctl.

• journalctl -u <service> filters entries for a specific unit, for example journalctl -u psmpsrv to see PSMP’s systemd‑level messages (start/stop, crashes, SELinux denials).

• journalctl -u <service> -f “follows” new entries, similar to tail -f, useful when restarting services and watching for errors live.

• You can add time filters, e.g. journalctl -u appmgr --since "10 min ago" to focus on the period when PTA started misbehaving.

Even when PSMP/PTA/SIA have their own text logs under /var/opt or /var/log/pta or Docker volumes, journalctl is still essential for OS‑level failures and permission issues.

2.3 SSH server config: sshd_config

OpenSSH server is configured via /etc/ssh/sshd_config, a text file of Keyword value entries interpreted by sshd at startup.

Important directives in a CyberArk context:

• AllowGroups – restricts SSH login to members of specific Unix groups, e.g. AllowGroups PSMConnectUsers maintenanceadmins; PSMP uses this in integrated mode to govern which Unix groups can access PSMP directly.

• AuthorizedKeysFile and TrustedUserCAKeys (or distro‑specific equivalents) – determine where SSH public keys and SSH CA public keys are read from, which is foundational for SIA’s SSH certificate‑based access.

• Custom parameters like PSMP_MaintenanceUsers – parsed by CyberArk’s hardened SSHD to decide which users bypass the PSMP gateway and log into the PSMP OS itself for maintenance.

After edits you must restart SSH (systemctl restart sshd or /etc/init.d/sshd restart on older systems); if the syntax is invalid, SSH fails to restart and you can lock yourself out, so always test changes from an existing open session.

2.4 File permissions and ownership

Most operational issues on PSMP/PTA/SIA Linux hosts are caused by incorrect permissions.

• ls -l shows owner, group, and permission bits (e.g. -rwxr-xr-x), which you use to verify that CyberArk binaries (like CreateCredFile or psmpsrv scripts) are executable by the right user (typically root).

• chmod 755 <file> makes a file executable for owner and readable for others; CyberArk docs and community material consistently show making CreateCredFile and PSMP RPM scripts executable this way before use.

• chown / chgrp adjust ownership; they matter if logs or data directories end up owned by the wrong user, causing components like MongoDB (PTA) or PSMP to fail to write logs or data.

Standardize file ownerships (root:root for binaries, dedicated service accounts for DB/process data) and ensure log directories permit write‑access for their respective service users.

3. PSM for SSH (PSMP) – architecture, workflow, and Linux internals

3.1 What PSMP does

PSMP is an SSH proxy that “takes over” SSH logins to itself and turns them into brokered sessions to target systems, using credentials and policies stored in the Vault / Privilege Cloud.

From the user’s point of view, they connect with an SSH client to the PSMP host using a special username syntax or interactive prompts; PSMP then asks who they are in the Vault, which target they want, and which account, and finally opens an SSH session to that target while recording and auditing the session.

3.2 PSMP directory structure and what each path means

CyberArk uses a consistent layout on Linux PSMP servers:

• /opt/CARKpsmp – program files (binaries and scripts).

  • Contains the PSMP server executable, setup scripts like psmp_setup.sh, and utilities such as CreateCredFile used to generate encrypted credential files for Vault authentication.

• /etc/opt/CARKpsmp – configuration files.

  • Includes vault.ini (Vault address, port, authentication parameters), environment definitions, and various PSMP policy/configuration files.

• /var/opt/CARKpsmp – logs and runtime data.

  • logs/ holds operational logs like PSMPConsole.log and OpenSSH component logs.

  • temp/ holds installation and setup logs (psmp_setup.log) for troubleshooting registration or upgrade failures.

• /opt/CARKpsmpadb and /var/opt/CARKpsmpadb – AD Bridge binaries and logs, used when PSMP integrates with Active Directory to resolve users/groups or perform Kerberos flows.

This separation lets you patch the OS and reinstall PSMP without disturbing configuration and logs, and simplifies backups and monitoring.

3.3 Key PSMP configuration files and parameters

vault.ini (e.g. /etc/opt/CARKpsmp/Vault/vault.ini) connects PSMP to the Vault.

• Contains fields like Address, Port, User, as well as references to an encrypted credential file generated by CreateCredFile.

• If the Vault connection breaks (e.g. DNS change, certificate or port change), PSMP may still accept SSH connections but cannot fetch credentials; you’ll see authentication errors in PSMPConsole.log that ultimately trace back to vault.ini

sshd_config (OpenSSH server config) is where PSMP integrates its gateway behavior:

• PSMP_MaintenanceUsers user1,*user2,user3*,*user4* – defines which local users are allowed to log directly into the PSMP host for OS maintenance, bypassing the PSMP proxy logic.

  • Wildcards let you express patterns (starts with, ends with, contains) to match naming standards (e.g. *mng for all management accounts).

• AllowGroups PSMConnectUsers <MaintenanceGroup1>..<MaintenanceGroupN> – in integrated mode, tells PSMP which Unix groups may log in directly; other SSH logins are intercepted and brokered by PSMP.

This ensures that by default all non‑maintenance SSH logins are treated as privileged sessions that must go through CyberArk policy and auditing, while only a very small set of users can administer the PSMP server itself.

3.4 PSMP services and the psmpsrv control script

PSMP exposes a logical service psmpsrv, managed either by systemd or via SysV init scripts depending on the OS.

• On systemd: systemctl start|stop|status psmpsrv is the preferred control interface.

• On SysV systems: /etc/init.d/psmpsrv {start|stop|restart|status} [{psmp|psmpadb}] calls the underlying startup scripts; specifying psmp or psmpadb controls only the main proxy or the AD Bridge.

psmpsrv scripts often export environment variables like PSMPOpenSSHTraceLevels and PSMPOpenSSHLogFolder, which instruct the OpenSSH component used by PSMP where and how verbosely to log.

3.5 PSMP logs: what they contain and how to use them

Main service logs (/var/opt/CARKpsmp/logs):

• PSMPConsole.log – captures PSMP core events: startup/shutdown, Vault connection successes/failures, incoming SSH connections, authorization decisions, and major errors.

• AD Bridge logs (/var/opt/CARKpsmpadb/logs/ADBConsole.log) – detail directory lookups, Kerberos ticket issues, and problems resolving users/groups from AD.

OpenSSH component logs are controlled with environment variables:

• PSMPOpenSSHTraceLevels – sets the verbosity of OpenSSH logging; higher values generate detailed handshake and channel debug information, useful for diagnosing cipher, key, or KEX problems but can quickly fill disk.

• PSMPOpenSSHLogFolder – directs OpenSSH logs to a specific folder (e.g. /var/opt/CARKpsmp/logs/components), keeping them separate from PSMPConsole output.

Setup logs (/var/opt/CARKpsmp/temp/psmp_setup.log) record what psmp_setup.sh did: Vault registration steps, environment creation, failures to reach the Vault, and permission issues during installation.

A typical troubleshooting sequence:

1. systemctl status psmpsrv – confirm whether PSMP is running.

2. journalctl -u psmpsrv -f – watch systemd‑level messages during restart for SELinux, port binding, or missing library errors.

3. tail -f /var/opt/CARKpsmp/logs/PSMPConsole.log – read PSMP‑specific errors (Vault unreachable, account not found, permission denied).

4. If needed, enable OpenSSH tracing and inspect component logs for low‑level SSH handshake problems.

4. How a PSMP SSH connection works (internal workflow)

Here’s the internal flow when a user connects to a target via PSMP:

1. User initiates SSH to PSMP – using a connection string like ssh vaultuser@root@target.example.com@psmp.example.com or equivalent variation supported by your connection components.

2. PSMP’s SSHD receives the connection – the Linux sshd process on PSMP sees the incoming SSH, parses sshd_config, and detects that this is not a maintenance user/allowed group; the CyberArk integration intercepts the login and passes control to PSMP logic instead of starting a standard shell.

3. Gateway prompts for details (if needed) – PSMP prompts for Vault username, Safe, target system, and target account based on your PSM for SSH connection component definition; this maps the user’s SSH connection to a specific privileged account object in the Vault or Privilege Cloud.

4. PSMP authenticates to the Vault – using vault.ini and an encrypted credential file produced by CreateCredFile, PSMP logs into the Vault under its technical user.

5. PSMP fetches credentials and policies – it identifies the correct privileged account and platform, retrieves the secret (password or SSH key) or references, and applies relevant access and recording policies.

6. PSMP opens SSH to the target – acting as an SSH client, PSMP connects to the target host using the vaulted credentials (and possibly jump hosts or SSH tunneling as configured).

7. Session brokering and recording – PSMP proxies all traffic between the user and the target; if text/video recording is enabled, it captures keystrokes and terminal output and forwards them into the PSM/Privilege Cloud recording infrastructure.

8. Audit events – commands and key events (e.g. file transfers) are logged and made available in central Monitoring/Audit pages for search and playback.

From the Linux OS perspective, this is an enhanced SSHD plus a userland proxy process, so your responsibilities are to keep SSHD healthy, PSMP services running, and connectivity to Vault and targets stable.

5. PTA – Linux architecture, files, and logs

5.1 What PTA does and how it’s built

PTA ingests events and logs from PAM (Vault, PVWA, PSM/PSMP, etc.) to detect risky privileged behavior such as unusual access times, abnormal commands, or suspicious login patterns.

It runs on a hardened Linux host with a stack of components (Tomcat web app, MongoDB, ActiveMQ, nginx, exporters, Prometheus), and CyberArk expects you to treat it like an appliance: you patch the OS using dnf, and PTA installers handle bundled third‑party components.

5.2 PTA directories and what they contain

PTA file locations are grouped by purpose:

• Data (/var/lib/pta/...)

  • /var/lib/pta/ptadb – MongoDB data files; contain PTA events, configuration, and analytics state.

  • /var/lib/pta/ptaq – ActiveMQ queues and topics, which decouple ingest from analytics processing.

• Configuration (/etc/opt/pta/...)

  • /etc/opt/pta/ptadb – MongoDB configuration (ports, paths, tuning parameters).

  • /etc/opt/pta/app – general PTA application configs (integration endpoints, thresholds, etc.).

  • /etc/opt/pta/plugins – plugin scripts or modules for specialized analyses or integrations.

• Logs (/var/log/pta/...)

  • /var/log/pta/app – PTA app logs (Tomcat/Java); includes diamond.log.

  • /var/log/pta/ptaq – ActiveMQ logs; see message broker performance and errors.

  • /var/log/pta/ptadb – MongoDB logs for PTA, important for diagnosing DB failures and performance.

  • /var/log/pta/utility – logs from maintenance utilities (e.g. domain mapping changes, log‑level adjustments).

  • /var/log/pta/statistics – metrics about processing throughput and pipeline health.

This structure helps you separate code (CyberArk‑managed), configuration (backed up and versioned), and data/logs (monitored for capacity and retention).

5.3 PTA utilities and UTILITYDIR explained

PTA ships with a set of utilities accessible through a “utility directory” (often exposed via the UTILITYDIR alias).

Entry point:

sudo /opt/tomcat/utility/run.sh

This script launches a menu or dispatches to specific utility scripts under the same directory.

Key utilities and what they do:

• authorizedSourceHostsConfiguration.sh – defines which IP addresses or hosts are allowed to send logs/events to PTA; use it to restrict ingestion to known PAM components and collectors.

• domainMappingConfiguration.sh – maps domain FQDNs and NetBIOS names to canonical identifiers so events referencing the same AD domain are correlated correctly.

• domainsUtil.sh – inspects and updates internal lists of domain controllers; you run it when adding/removing DCs or changing AD replication topology.

• dateAndTimezoneConfiguration.sh – configures time and timezone, which must match your enterprise standard to align PTA alerts with PAM and SIEM events.

• ChangeLogLevel.sh – changes log level for PTA components (for example, to trace for deep troubleshooting) without editing log4j configs manually.[

• changeComponentResource.sh – adjusts resource allocations for components where PTA exposes tunable parameters.

• import_PTA_data.sh – restores or imports PTA configuration/data from another instance (e.g. migrations, DR).

• vaultPermissionsValidation.sh – checks and optionally repairs Vault permissions required by PTA; useful when onboarding or after Vault changes.

Using these tools keeps your configuration consistent with CyberArk’s expectations and simplifies support.

5.4 PTA services and Linux commands

PTA components are orchestrated by a central service manager, commonly called appmgr:

• systemctl status appmgr – shows if PTA’s orchestrator is running; if it’s down, PTA is effectively offline.

• systemctl restart appmgr – cleanly restarts PTA’s web app, DB, broker, and related components after config or log‑level changes.

Although there are underlying services (MongoDB, Tomcat, nginx, exporters), manage them through appmgr unless CyberArk support directs otherwise, to avoid inconsistent startup orders.

5.5 PTA logs in practice

Important logs and how to use them:

• diamond.log (in /var/log/pta/app) – main PTA application log; contains startup messages, Vault connectivity, event processing errors, and alert generation traces.

• prepwiz.log – tracks what the installation/configuration wizard did; when installation fails, this is the first log to check.

• diamond-utility.log – records operations performed by utility scripts, useful for reconstructing configuration changes.

• statistics.log (under /var/log/pta/statistics) – provides insight into throughput and performance; spikes or drops can indicate ingest problems.

• MongoDB and ActiveMQ logs (under /var/log/pta/ptadb and /var/log/pta/ptaq) – show DB and broker‑level issues such as lockups, disk full, or connection limits.

When instructed to collect more data, you typically run:

ChangeLogLevel.sh -c all -l trace -norestart systemctl restart appmgr

Then reproduce the issue, collect logs, and revert to a lower log level to prevent disk exhaustion.

6. SIA – Linux, SSH, and connectors

6.1 SIA’s role in SSH and infrastructure access

Secure Infrastructure Access (SIA) is CyberArk’s modern, SaaS‑backed access mechanism that provides VPN‑less, just‑in‑time access to Linux, Windows, databases, and Kubernetes.

It supports both vaulted access (leveraging credentials in PAM Self‑Hosted or Privilege Cloud) and Zero Standing Privileges (ZSP) using ephemeral SSH certificates for Linux, while centralizing policy and session monitoring.

6.2 SIA connectors on Linux and their files/logs

SIA uses connectors deployed into your network; for Linux‑heavy environments these are often containerized on Linux hosts.

Key filesystem locations:

• Connector log volume – /var/lib/docker/volumes/remote-access-logs/_data/ (or similarly named) holds connector logs:

  • Connector.log – high‑level behavior: startup, connection to SIA SaaS, session routing.

  • nginx-output.log – HTTP/TLS issues between users and connector.

  • Protocol logs (e.g. SSH client output) – handshake‑level information for specific sessions.

• Hardening log – /opt/remote-access-hardening-log.txt documents security hardening steps executed on the connector host.

• Remote Access CLI logs – ~/snap/remote-access-cli/common/logs/connector-cli.log record CLI operations for managing connectors and collecting diagnostics.

• Collected logs – running get-logs via the CLI bundles connector logs into ~/snap/remote-access-cli/common/savedLogs/ for support.

From a Linux admin standpoint, you treat connectors like any containerized service: use docker ps and docker logs for runtime health, monitor log volumes, and forward logs to SIEM.

6.3 SIA settings relevant to Linux SSH

On the SIA Settings page you configure several options that directly influence Linux SSH access.

• PAM / Privilege Cloud connectivity – selects PAM Self‑Hosted vs Privilege Cloud and provides connection details; SIA uses this to retrieve vaulted credentials.

• MFA caching – controls if/for how long MFA responses can be reused and ties them to IP/device; audit events note acquisition and release of MFA caching tokens.

• SSH host key (fingerprint) validation – enforces strict validation of SSH server fingerprints; SIA records the fingerprint on first use and raises audit events if it later changes.

• SSH session audit and commands – configures whether SIA records full session video, commands only, or both; these generate events such as “SSH session audit” and “SSH command audits” tied to individual sessions.

These settings not only shape user experience but determine how much forensic data is available for Linux SSH sessions.

7. How an SIA SSH connection works

7.1 Vaulted SSH access flow

In vaulted mode, SIA uses a vaulted account (from PAM Self‑Hosted or Privilege Cloud) but still applies JIT policy and centralizes auditing.

1. User requests access – through SIA UI/CLI they choose a Linux target and a vaulted access option; SIA evaluates policy (user, target, risk, time) to decide whether to allow it.

2. SIA talks to PAM – if approved, SIA contacts PAM Self‑Hosted or Privilege Cloud, as configured in Settings, to obtain the privileged credential or to orchestrate a session using it.

3. Connector establishes SSH – the connector (on a Linux or Windows host, but often fronting Linux networks) opens an SSH connection to the target using the vaulted credential while brokering a secure channel from the user’s client to the target.

4. Session monitoring and audit – SIA records commands (and optionally video) and generates audit events that appear under categories like “SIA SSH sessions” and “SSH command audits.”

5. Session closure and rotation – once done, PAM policies can rotate the credential; the user is left with no reusable secret or persistent access route.

Linux targets see this as a normal SSH login from connector IPs, but identity and authorization are controlled centrally by SIA and PAM.

7.2 JIT SSH certificates flow

In certificate mode, SIA leverages an internal SSH Certificate Authority to issue short‑lived per‑session certificates.

1. Bootstrap trust – SIA’s SSH CA public key is deployed to Linux hosts (e.g. via TrustedUserCAKeys or equivalent), so sshd accepts certificates signed by that CA for specific principals.

2. User requests access – user selects a target and an SIA access option that uses JIT certificates; policy evaluation decides whether to grant ephemeral access.

3. SIA issues certificate – SIA generates an SSH certificate bound to the user and target, potentially with command restrictions and a strict validity window (minutes).

4. SSH handshake – the certificate is presented during the SSH handshake; Linux sshd validates it against the CA key and policy, allowing access without a static key or password.

5. Expiry and audit – the certificate expires quickly and cannot be reused; audit events capture issuance and usage, alongside detailed SSH session records where configured.

This implements Zero Standing Privileges for Linux: no long‑lived SSH keys or passwords are stored on the host, and all access is time‑bounded and centrally logged.

8. Linux log strategy for PSMP, PTA, and SIA

Design your logging strategy so both CyberArk‑specific and OS‑level events from Linux hosts are visible in your SIEM.

PSMP:

• Forward /var/opt/CARKpsmp/logs/PSMPConsole.log to detect Vault connectivity issues, repeated authentication failures, and configuration problems.

• Include /var/opt/CARKpsmpadb/logs/ADBConsole.log so AD connectivity issues, which can break group‑based policies, are visible.

PTA:

• Ingest logs from /var/log/pta/app, /var/log/pta/ptadb, /var/log/pta/ptaq, /var/log/pta/statistics, and /var/log/pta/utility to monitor app, DB, broker, metrics, and utility operations.

• Monitor OS logs (journalctl, /var/log/messages, or distro equivalents) for disk, SELinux, and network issues affecting PTA components.

SIA / connectors:

• Forward logs from /var/lib/docker/volumes/remote-access-logs/_data plus CLI logs from connector-cli.log to see connection failures, TLS issues, and SSH handshake problems.

• Correlate them with SIA’s centralized audit events (SSH sessions, fingerprints, MFA caching, ephemeral access) to get a complete picture of access and control.

Combine all this with Vault, PVWA, PSM/PSMP, and Privilege Cloud logs using vendor‑provided parsers so analysts can reconstruct who accessed what, when, from where, and with which Linux‑level effects.

9. “Must‑know” commands and configs – explained cheat sheet

9.1 PSMP

• systemctl status psmpsrv – primary command to check PSMP health; shows service state and recent failure messages.

• /etc/init.d/psmpsrv {start|stop|restart|status} [{psmp|psmpadb}] – older but still valid way to control PSMP and its AD Bridge on non‑systemd or mixed setups.

• tail -f /var/opt/CARKpsmp/logs/PSMPConsole.log – real‑time view of PSMP behavior when reproducing issues.

• vi /etc/ssh/sshd_config + PSMP_MaintenanceUsers proxymng,root1 – configure which local users are allowed direct SSH access to PSMP for OS maintenance.

• chmod 755 CreateCredFile + ./CreateCredFile – enable and run the credential utility to create the encrypted password file referenced by vault.ini.

9.2 PTA

• systemctl status appmgr – verifies PTA’s orchestrator is running; if down, PTA analytics and UI are offline.

• ChangeLogLevel.sh -c all -l trace -norestart – temporarily increase logging to trace level across components for troubleshooting.

• ls -R /var/log/pta – quickly identify what logs exist and which are growing fastest, for capacity and troubleshooting.

• UTILITYDIR / /opt/tomcat/utility/run.sh – central entry point for supported configuration changes (domain mappings, authorized senders, Vault permission checks).

9.3 SIA / connectors

• docker ps + docker logs <connector-container> – confirms connector containers are running and reveals runtime errors.

• ls /var/lib/docker/volumes/remote-access-logs/_data – lists connector log files used for diagnostics and SIEM forwarding.

• get-logs (Remote Access CLI) – collects and bundles connector logs in ~/snap/remote-access-cli/common/savedLogs/ for support.

This guide is meant to be a practical, opinionated field manual for using Linux in the context of CyberArk PAM Self‑Hosted and Privilege Cloud, especially around PSMP, PTA and SIA. It gives you the concepts, workflows, commands, config files and logs you’ll touch day‑to‑day as a CyberArk professional.

For full product detail, always refer to CyberArk’s official documentation for PAM Self‑Hosted, Privilege Cloud, PSMP, PTA and SIA – that is the authoritative source for supported architectures, hardening requirements and version‑specific parameters, and should be your reference before making any change in production.

At the same time, remember that Linux itself is far broader than what’s covered here. If you want to deepen your Linux skills beyond the CyberArk realm, a good path is:

• Start with a structured Linux command overview (e.g. “top 30–50 Linux commands”) and actually practice them on a lab VM, focusing on filesystems, processes, networking and permissions.

• Use the manual pages (man <command>) and built‑in help (<command> -h) every time you meet a new tool; treat them as your first line of documentation.

• Explore foundational resources like the Linux Documentation Project and distro tutorials (Fedora, RHEL, SUSE, etc.) to understand how services, packaging, and security are implemented across environments.

If you combine that general Linux learning with the CyberArk‑specific patterns described in this guide, you’ll be in a strong position not just to “keep the lights on,” but to design, review and troubleshoot complex PAM and Privilege Cloud deployments with confidence on any Linux platform.