When you give someone SSH access to a Linux server, what exactly have you given them?
Think about that carefully before answering. Because the instinct is to say “access to do the thing they were brought in to do.” But what the SSH session actually provides, absent any command-level restrictions, is an interactive shell with whatever privileges the account carries. That is not the same thing. Not even close.
A developer given SSH access to restart a service has, in the same session, the technical ability to read log files, navigate the file system, view running processes, install packages if the account permits it, modify configuration files, and run any command the system allows for that user. The restart-the-service use case is a one-liner. The SSH session is a general-purpose compute environment.
Most organisations know this is true and treat it as acceptable risk. This blog explains why that calculation is wrong, and what enforcing least privilege at the command level actually looks like technically.
Where the Principle of Least Privilege Stops Short in Most Environments
Least privilege is well understood as a principle and inconsistently applied as a control. At the application layer, role-based access control is reasonably mature in most organisations. Users have the permissions their role requires, and access is reviewed periodically. At the server layer, the model collapses.
The reason is architectural. SSH provides an authenticated shell. Once the shell opens, what the user can do is governed by the Unix permission model on the target system, not by any IAM policy. The IAM system verified the identity. It has no further influence over what happens inside the session.
This means privileged access management that stops at session authentication is not enforcing least privilege. It is enforcing authenticated access, which is a different and weaker control. If you want to understand the full scope of what PAM is supposed to cover, the PAM explained blog covers the complete framework, including where session-level controls fit within the broader privileged access architecture.
There are two common approaches organisations use to address this within the Unix permission model, and both have significant limitations in enterprise environments.
sudo policy files. Restricting commands through the sudoers file on each target server is technically viable but operationally brittle. Every change to the permitted command set requires an update to the sudoers file on every affected server. In environments with dozens or hundreds of servers, this creates a configuration management burden that leads to inconsistency. Servers end up with different policies because updates are applied inconsistently. Over time, the gap between what the policy says and what is actually enforced on each server grows.
The deeper problem is that sudoers management happens at the server layer, disconnected from the identity and access management system. When a user’s role changes or they leave the organisation, the sudoers entries do not automatically update. This is the same offboarding gap that automated provisioning and de-provisioning address at the application layer, but misses entirely at the server layer when PAM is not in place.
Restricted shells. Rbash and similar restricted shell environments limit certain operations within the shell itself. They are easy to escape in ways that are well documented, and they are not a serious control in environments where the user has any technical sophistication.
Neither approach gives you what you actually need: per-user, per-server command restrictions managed centrally, enforced at the session layer, and connected to your IAM system so that changes propagate automatically.
What Happens When the Restriction Model Breaks Down
The risk is not abstract. Consider a third-party vendor brought in to perform database maintenance on a production server. They need to connect to the database service, run specific diagnostic queries, and restart a process if needed. The IT team grants SSH access to the relevant server.
During the session, the vendor is working on the task they were given. But nothing technical prevents them from exploring the file system, reading application configuration files that may contain connection strings for other systems, viewing the contents of log files that include user activity or transaction data, or running commands outside the scope of their engagement.
Most vendors would not do this deliberately. But the risk is not primarily deliberate misuse. It is the combination of accidental exposure and the absence of any audit evidence that would surface it. If the session produces only a login and logout timestamp, there is no record of what was accessed or explored. The SMART Audit Trails capability in Akku PAM closes this specific gap, capturing every command executed during an SSH session with a precise timestamp. But audit trails tell you what happened after the fact. Granular Access Control prevents what should not happen in the first place.
When a compliance audit asks you to demonstrate that your third-party vendor had access scoped to their specific task, an SSH session with no command restrictions and no command-level audit log does not satisfy that requirement. Not under ISO 27001 Annex A.9, not under DPDPA’s data processor governance requirements, not under the RBI Cybersecurity Framework’s privileged access monitoring requirements. For manufacturing organisations managing contractor access to OT-adjacent systems, or financial services firms operating under SEBI’s CSCRF, this is a documented audit gap, not a theoretical concern.
What Command-Level Restriction Actually Requires at the Architecture Level
Effective command-level restriction needs to satisfy three technical requirements simultaneously.
The restriction must be enforced at the session layer, not the server layer. Configuration on the target server is operationally unsustainable at scale and disconnected from the IAM system. The session proxy is the correct enforcement point because it sees every command before execution and has access to the identity and policy context.
The restriction must be per user per server. The same user on different servers may require different permitted command sets. Different users on the same server may require different permitted commands. A flat policy that applies the same restrictions to everyone on a given server does not map to real operational requirements.
The restriction must be connected to the identity system so that policy changes, role changes, and offboarding propagate automatically without a separate remediation step at the server layer.
How Akku PAM Enforces This
Granular Access Control in Akku PAM allows administrators to define a permitted command list for each user on each SSH server, configured from the Akku Admin Console. Different users on the same server can have different permitted command sets. The same user on different servers can have different permissions.
Enforcement happens at the AkkuReka session layer. When the user executes a command inside the SSH session, it is checked against their permitted list in real time before execution on the target server. If the command is permitted, it executes normally. If it is not on the list, it is blocked at the point of execution, regardless of the user’s underlying system privileges on the server. This requires no agent on the target server and no changes to the server configuration.
Because enforcement happens at AkkuReka rather than the server layer, changes to permitted command lists propagate immediately across every server in scope. There is no sudoers file to update, no configuration management job to run, no inconsistency between servers.
SMART Audit Trails capture every command executed during the session, including every command that was attempted and blocked, with a precise timestamp. The combination of Granular Access Control and SMART Audit Trails provides two things neither delivers alone: technical enforcement of the intended access scope, and a complete logged record of how that scope was used. Both are exportable as compliance evidence for ISO 27001, RBI, DPDPA, SOC 2, and PCI-DSS requirements.
The just-in-time access layer adds another dimension on top of command-level restriction. Rather than granting standing SSH access that persists indefinitely, JIT access means elevated access is requested, approved through a configurable chain, granted for the duration of the task, and automatically revoked when the session ends. When you combine JIT access with Granular Access Control, the result is privileged access that is time-bounded, scope-bounded, and command-bounded simultaneously.
The security hardening and zero-trust posture layer applies across every session that AkkuReka governs: adaptive MFA, MDM device compliance enforcement, IP and location restrictions, and time-of-day policies. The same policy engine that governs access to your SaaS applications governs access to your servers. There is no separate security posture for infrastructure versus applications.
When an employee or contractor is offboarded from Akku IAM, their infrastructure access is revoked immediately through AkkuReka. The permitted command lists are irrelevant at that point because the session proxy will not open a session for a deprovisioned identity. There is no separate step at the server layer.
For organisations with third-party vendor access to production infrastructure, Granular Access Control enables a specific capability that is otherwise architecturally difficult to achieve: contractors and vendors can be given SSH access scoped precisely to the tasks they need to perform, with a technical boundary preventing them from exceeding that scope. This is directly relevant for ITeS and BPO organisations managing vendor access to client environments, and for manufacturing organisations where third-party maintenance contractors regularly need server access scoped to specific operational tasks.
Before You Move On
Pull the sudoers configuration from three production servers in your environment. For each server, answer these questions.
Does the current configuration accurately reflect the minimum commands each user requires for their current role, or does it reflect the configuration that was set up when the server was provisioned and has not been meaningfully reviewed since?
If a contractor completed their engagement six months ago and their account was disabled in Active Directory, do the sudoers entries on these servers still reference their account?
If a user exceeds their intended scope during an SSH session today, where in your current logging setup would that show up?
If the policy on these servers needed to change tomorrow, how many systems would you need to update manually, and how confident are you that the update would be applied consistently across all of them?
See How Akku PAM Granular Access Control Works | Talk to the Akku Team
Questions Infrastructure and Security Teams Ask About Command-Level Access Control
Q: Why is SSH access considered all-or-nothing even when role-based access control is in place at the application layer?
A: RBAC at the application layer controls what users can do within applications. SSH access operates at the operating system layer, below the application. Once an SSH session is open, the user has an interactive shell governed by Unix file permissions and sudo policies on the target server, not by any IAM policy. The IAM system verified the identity at the point of authentication and has no further influence inside the session. Least privilege at the application layer and least privilege at the server layer are two separate and independent controls.
Q: What are the limitations of using sudoers files to restrict commands?
A: The sudoers approach works in principle but fails operationally at scale. Every change to the permitted command set requires updating the sudoers file on every affected server individually. In environments with dozens or hundreds of servers, this creates configuration drift where the effective policy on each server diverges from the intended policy over time. Sudoers management is also disconnected from the IAM system, meaning that role changes and offboarding do not automatically propagate to server-level command restrictions. AkkuReka enforces command restrictions centrally at the session proxy layer, eliminating both the configuration drift problem and the IAM disconnection problem.
Q: How does command-level restriction differ from session recording?
A: Session recording captures what happened. Command-level restriction prevents what should not happen. Recording tells you after the fact that a user ran a command they were not supposed to run. Restriction blocks the command before it executes. SMART Audit Trails handle recording. Granular Access Control handles restrictions. Together, they provide enforcement plus forensic evidence.
Q: Does command-level restriction require installing an agent on target servers?
A: Akku PAM’s Granular Access Control does not require any agent on target servers and no changes to server configuration. Enforcement happens at the AkkuReka session proxy layer, which intercepts every command before it reaches the target server. The server receives only commands that passed the permitted list check.
Q: How are permitted command lists managed when contractors or third-party vendors need temporary access?
A: Permitted command lists are configured per user per server from the Akku Admin Console. For a contractor engagement, the administrator creates a list specific to that contractor on the specific servers they need to access. Just-in-time access can be layered on top, so the access is also time-bounded. When the engagement ends, and the contractor’s IAM identity is deprovisioned from Akku IAM, AkkuReka stops opening sessions for that identity immediately. No separate cleanup of server-level configurations is required.
