Your PAM platform covers privileged access. Ask your infrastructure team how much of it, and the answer will involve a percentage. Ask which systems are excluded, and the answer will almost certainly include Linux servers accessed directly over SSH.
PAM coverage metrics count the accounts that are under management on the PAM platform. A Windows server with RDP access through the PAM session proxy is counted. A Linux server that engineers connect to directly via SSH, bypassing the PAM platform entirely because the integration was deferred or never built, is not counted. The metric looks acceptable. The exposure is real.
The sessions that fall outside PAM coverage on Linux are not low-risk exceptions. SSH access to Linux servers is where root operations happen, where service account credentials are used, where configuration changes are made, where database queries run as administrative users. These are the highest-privilege sessions in most infrastructure environments. They are also the sessions most likely to be conducted outside the PAM governance layer, with no session recording, no keystroke logging, no approval workflow, and no credential management.
This blog covers why Linux SSH access ends up outside PAM coverage in most deployments, what that gap looks like in terms of audit evidence and security posture, and how Akku PAM’s SSH session proxy closes the coverage gap without requiring agents on target systems.
What PAM Coverage Metrics Actually Measure
PAM platforms measure coverage in terms of accounts under management: privileged accounts whose credentials are stored in the vault, whose sessions flow through the session proxy, and whose access is governed by the platform’s approval and policy workflows. A target system is considered covered when the PAM platform is positioned between the user and the system for every privileged session.
Coverage gaps occur when target systems exist in the environment that are not connected to the PAM session proxy. Users access those systems directly, using credentials they hold independently of the vault. The sessions are not recorded. The commands are not logged. The credentials are not managed. The access governance framework that applies to covered systems does not apply.
The gap is often not visible in the PAM dashboard because the dashboard shows the systems that are under management. Systems that were never connected to the PAM platform do not appear as gaps. They simply do not appear. An accurate coverage assessment requires comparing the PAM platform’s target system inventory against the full infrastructure estate and identifying the systems that are present in one but not the other. For most organisations that have not conducted this comparison explicitly, the gap is larger than expected.
Why Linux SSH Stays Outside PAM Coverage
Linux servers are frequently the last category of infrastructure to be brought under PAM management for several reasons that are individually defensible but collectively produce a significant governance gap.
First, the integration complexity argument. Windows RDP sessions can be proxied through most PAM platforms with minimal configuration because RDP is a well-standardised protocol with broad support in PAM tooling. SSH integration requires configuring the SSH session proxy to intercept connections, managing SSH key rotation alongside password credentials, and handling the variety of SSH-based access patterns in a Linux environment: interactive shells, SFTP file transfers, SCP copies, port forwarding, and multiplexed sessions. This is manageable but requires more integration effort than RDP, and the effort is deferred when PAM deployment is phased.
Second, the operations team resistance argument. Infrastructure engineers who use SSH daily for server management, deployment operations, and troubleshooting have workflows built around direct SSH access. Introducing a session proxy layer changes the connection workflow. Engineers who connect through a PAM portal instead of directly via their SSH client experience friction in their normal operations. This resistance is manageable with a well-designed onboarding process, but it is a real factor in why Linux SSH integration is deferred in PAM deployments that prioritise quick wins.
Third, the legacy argument. Many Linux servers in production environments have been accessible via SSH for years, with access managed through local user accounts, SSH key pairs distributed informally, and sudo configurations that are maintained operationally rather than governed centrally. Bringing these systems under PAM management requires cleaning up the existing access model, which is a project in itself. The cleanup is deferred until the integration work is scheduled, and both items stay on the backlog.
The result is a PAM deployment that covers a high percentage of Windows infrastructure while leaving Linux SSH access outside the governance framework. The coverage metric reflects the Windows coverage. The Linux gap is not measured.
What Ungoverned SSH Sessions Look Like Versus PAM-Proxied Sessions
A privileged SSH session on a Linux server that is not under PAM management produces the following evidence trail: an authentication event in the system’s auth.log showing the user connected, and a session duration. What it does not produce is any record of what the user did inside the session.
The commands executed, the files accessed, the configurations changed, the processes started or stopped, the queries run against databases: none of this is captured in the server’s standard authentication log. The server’s shell history file captures some commands, but shell history is stored locally on the server, is not tamper-evident, can be cleared by the user, and requires individual server access to retrieve. It is not an audit-grade evidence source.
A PAM-proxied SSH session through AkkuReka produces a fundamentally different evidence set. Every keystroke is captured in a structured log with millisecond-precision timestamps. The full session is recorded as a searchable SMART Audit Trail that can be replayed in the Akku admin console. Commands that match blocked patterns, attempts to escalate privileges, file operations on sensitive paths: all are captured and flagged in real time. The session recording is sealed on session close, stored with AES-256 encryption, and cannot be modified or deleted by the session user.
The difference in evidence quality is the difference between knowing that a privileged user connected to a server and knowing exactly what they did while they were there. For a post-incident investigation, the PAM-proxied session record is the one that answers the investigation’s questions. The ungoverned session record answers only the first question, who connected, and leaves everything else to manual reconstruction.
Why SSH Is Your Highest-Risk Ungoverned Access
Root Access
Linux server administration frequently involves root access, either through direct root login or through sudo elevation. Root access on a Linux server is effectively unrestricted: a root session can read any file, modify any configuration, delete any data, and create or remove any user account on the system. Root sessions that occur outside the PAM governance framework leave no command-level audit trail. The organisation cannot determine what a root session did without reviewing shell history on the server itself, assuming the history was not cleared and the server is still accessible.
Service Account Operations
Linux infrastructure frequently uses service accounts for scheduled processes, deployment pipelines, and application-to-infrastructure connections. Service accounts often hold elevated privileges because the processes they run require privileged operations. Service account credentials in many environments are static, shared across multiple users or systems, and never rotated because rotation requires updating every process that uses the credential. A service account credential that is used for direct SSH access to a production server, outside the PAM governance framework, is a privileged access pathway with no individual attribution, no session recording, and credentials that are widely known and rarely changed.
Blast Radius
Linux servers in most infrastructure environments are not isolated. They are networked systems with connections to databases, internal services, shared file systems, and other servers. A privileged SSH session on a Linux server can be used as a lateral movement pivot: once inside, the user can initiate connections to other systems on the internal network, use credentials stored on the server to authenticate to downstream systems, and access data that the server processes or stores. The blast radius of a compromised or misused privileged SSH session extends well beyond the initial target system.
How Akku PAM Closes the Linux SSH Coverage Gap
Akku PAM’s AkkuReka session proxy supports SSH proxying for Linux and Unix servers using an outbound worker model. The AkkuReka worker is deployed in the same network segment as the target Linux infrastructure. It initiates an outbound TLS 1.3 connection to the Akku cloud: no inbound firewall ports are required on the target network or target systems. No agent is installed on the Linux server. The worker handles all SSH session routing between the Akku cloud and the target.
When a user requests SSH access to a Linux server through Akku PAM, the session flows through AkkuReka. AkkuArka generates a unique ephemeral SSH credential for the session, injects it at the protocol layer, and revokes it permanently on session close. The user never sees the credential. The Linux server’s sshd receives a connection authenticated with a session-scoped credential that does not exist before the session opens and cannot be reused after it closes.
Every keystroke in the SSH session is captured in a structured log. The full session is recorded as a searchable SMART Audit Trail. Command blocking is configurable at the session role level: specific commands, patterns, or privilege escalation attempts can be blocked at the session proxy layer before they execute on the target system. A blocked command is logged with the actor identity, timestamp, and the blocked command string.
Bringing Linux SSH under PAM coverage does not require retiring existing SSH access workflows. The AkkuReka deployment runs alongside existing infrastructure. Access is redirected through the session proxy by updating the target entry in the PAM platform’s target system configuration. Engineers continue to use their existing SSH clients; the connection is proxied transparently. The session recording and command logging operate at the proxy layer without changes to the Linux server’s sshd configuration.
The Coverage Assessment
Pull the list of Linux servers in your infrastructure estate. Cross-reference it against the target system list in your PAM platform. The systems present in the infrastructure estate but absent from the PAM target list are your ungoverned privileged access surface. For each one, assess whether it is accessible via SSH by engineers with root or elevated privileges. If it is, and it is not under PAM coverage, every privileged SSH session on that server since the last time you checked is without a command-level audit trail.
For organisations under ISO 27001 A.8.15, which requires that user activity logs cover privileged access, or under PCI-DSS Requirement 10, which requires logging and monitoring of all access to system components in the cardholder data environment, an ungoverned Linux SSH pathway is a compliance gap regardless of what percentage of the rest of the infrastructure is covered.
Explore Akku PAM and AkkuReka | Talk to the Akku Team
Questions Security and Infrastructure Teams Ask About Linux PAM Coverage
Q: Does extending PAM coverage to Linux SSH require installing an agent on each Linux server?
A: No. Akku PAM uses an outbound worker model. The AkkuReka worker is deployed in the same network segment as the target Linux infrastructure on any Linux host, container, or VM. It initiates an outbound TLS 1.3 connection to the Akku cloud and handles all session proxying between the cloud and the target systems. No agent is installed on the target Linux servers. The server’s sshd configuration does not need to be changed. The worker has network-level access to the target servers on SSH port 22 and handles the proxied connection.
Q: How does AkkuArka manage SSH key credentials versus password credentials for Linux server access?
A: AkkuArka supports both SSH private key credentials and password credentials for Linux server access. For servers configured for key-based authentication, AkkuArka generates a per-session SSH key pair, registers the public key with the target server’s authorised_keys file at session open, and removes it at session close. The private key never leaves the Akku platform and is never visible to the user. For servers configured for password authentication, AkkuArka generates a unique session-scoped password, injects it at the protocol layer, and changes or removes it at session close. Both credential types are managed through AkkuVault with AES-256-GCM encryption.
Q: How does command blocking work at the SSH session proxy layer?
A: Command blocking in Akku PAM is configured at the session role level. Administrators define a command policy for each role that specifies blocked command patterns: specific commands, regular expression patterns, or privilege escalation indicators such as sudo su, su root, or chmod 777. When AkkuReka intercepts a keystroke sequence in an SSH session that matches a blocked pattern, it prevents the command from being transmitted to the target system, returns an appropriate response to the client indicating the command was blocked, and logs the blocked attempt with the actor identity, timestamp, and the blocked command string. The target server never receives the blocked command.
Q: What does the SMART Audit Trail for an SSH session contain?
A: The SMART Audit Trail for an SSH session captured through AkkuReka contains the full session recording with every keystroke logged at millisecond-precision timestamps, the complete command history in structured format indexed for search, the session metadata including actor identity, target system, session start and end timestamps, session duration, and termination reason. The recording is stored with AES-256 encryption in Akku’s audit storage and is accessible through the admin console for in-browser playback without requiring download. Forensic search within the recording is available by timestamp range, command string, or keyword. The audit trail record is append-only and tamper-evident.
Q: How does Akku PAM handle SSH access in air-gapped or isolated network environments?
A: Akku PAM’s outbound worker model is specifically designed for environments where inbound connections from external systems are not permitted. The AkkuReka worker is deployed inside the isolated network segment and initiates all connections outbound to the Akku cloud over TLS 1.3 on port 443. The isolated network’s firewall only needs to permit outbound HTTPS traffic from the worker host to the Akku cloud endpoints. No inbound ports are opened, and the target systems remain inaccessible from the internet. This model works equally well for air-gapped environments with restricted egress using proxy configurations, and for environments with private VPCs where the worker is deployed within the VPC.
Q: How does Akku PAM’s Linux SSH coverage integrate with the broader zero-trust access model?
A: Every SSH session request through Akku PAM is evaluated against the full zero-trust policy set before the session is opened: device posture from Akku MDM, geo-location, IP reputation, time-of-day, RBAC role, and JIT window if configured. A user whose device is not compliant with MDM policy, whose source IP is in a blocked range, or who is connecting outside their permitted access hours will not be granted a session regardless of whether they hold the correct SSH credentials. This extends the zero-trust access model to Linux SSH infrastructure, applying the same contextual access evaluation that governs application access to privileged infrastructure sessions.
