How do you configure PAM for sshd on AWS?

Configure PAM for sshd on AWS by enabling the PAM stack in sshd, then using a PAM module or control that enforces your authentication policy before shell access is granted. Keep access keys and temporary credentials tightly scoped, log authentication outcomes, and test fail-closed behaviour so SSH does not bypass PAM when the module is unavailable.

What PAM has to do before sshd hands over a shell

On Linux, sshd can call PAM during the login flow, so the practical question is not just whether SSH accepts a password or key. It is whether the SSH daemon is wired to consult the PAM policy stack before a session is opened, and whether that policy enforces the checks you actually want, such as local authentication, MFA, account state, or a custom gate for privileged access. The Linux hardening baseline should be your starting point for the SSH and PAM plumbing, not an afterthought, and a good reference is the Linux Server Hardening Guide.

That design matters because sshd and PAM are not interchangeable. sshd controls transport and session handling, while PAM decides whether the login path is allowed to continue. If the PAM stack is misordered, incomplete, or bypassed by an alternate auth path, you can end up with SSH access that looks controlled but is not actually governed by the policy you intended.

On AWS, the same pattern applies whether the target is an EC2 host, a bastion, or a managed Linux workload: the operating system still needs a local auth decision before shell access is granted. A PAM-backed SSH setup is therefore a host control, not an AWS control by itself. If you also rely on cloud credentials, temporary access, or break-glass accounts, the SSH policy and the cloud-side privilege model need to be aligned rather than treated as separate layers.

Which access paths need to be constrained alongside PAM?

PAM for sshd is only useful if the identities and credentials behind the session are already tightly scoped. That includes access keys, temporary credentials, local admin accounts, and any service or shared accounts that can reach the host. If those credentials can outlive the session, cross environments, or authorize broader cloud actions than the shell needs, PAM becomes a last checkpoint rather than a meaningful boundary. The Privileged Access Management Guide covers the surrounding access model for people and machines, including Privileged Access Management Guide.

For AWS-heavy environments, the more common failure is not PAM itself but privilege sprawl around it. SSH may be locked down on the host, while the same principal can still assume broader roles, fetch secrets, or create new access paths elsewhere in the account. A host login control is strongest when paired with short-lived access, explicit approval for elevation, and clear separation between interactive admin use and automated operations.

That is why session-level controls still matter. If a PAM rule permits access, you still want logging, session visibility, and a way to prove who approved the session and what happened during it. If it denies access, you want the denial to be deliberate and traceable, not a side effect of a broken module or a missing dependency.

How do you make the configuration fail closed instead of silently bypassing policy?

The most important implementation detail is whether sshd fails closed when PAM is unavailable or misconfigured. The point of the setup is lost if a module crash, package issue, or configuration drift causes SSH to fall back to an easier path. A disciplined build should test both the successful path and the failure path, so you know exactly what happens when the PAM stack cannot complete its check. The Just-in-Time Access and Zero Standing Privilege Guide is useful here because it frames temporary elevation as a controlled event, not a permanent privilege state.

In practice, that means validating the full login journey: sshd loads PAM, PAM consults the right modules in the right order, the intended policy is enforced, and the session is denied when the policy cannot be evaluated. You should also verify that administrative fallback accounts are excluded from the same blind spots, since break-glass access is the first place teams discover that “secure by policy” was really “secure when everything worked”.

Logging belongs in the same design conversation. If the host accepts or denies access, the event should be attributable to a user, source, and policy decision. Without that, you can neither prove enforcement nor investigate whether the SSH path was used during an incident.

Risk and Threat Considerations

Misconfigured PAM on sshd creates two kinds of exposure: access can be granted when it should not be, or a broken module can lock out legitimate operators at the worst possible moment. In AWS environments, that becomes more serious when the same host is used for privileged administration, because a weak SSH gate can expose the same path that leads to cloud credentials, instance metadata, or higher-value management tooling.

Failure mechanism: sshd may accept an alternate authentication path, or a failing PAM stack may be treated as a non-blocking condition instead of a hard stop. That opens the door to policy bypass, privilege drift, and loss of assurance around who actually reached the shell.

Impact: Unauthorized shell access, broader cloud compromise through a foothold host, and operator lockout during an incident are the main consequences. If the host also stores secrets or can reach admin interfaces, the blast radius can extend well beyond the box itself.

Practitioner Guidance

What to verify: Confirm that sshd is actually invoking PAM on the login path you use, and test at least one normal login and one controlled failure scenario. If the login still succeeds when the intended PAM module is disabled or unavailable, the control is not dependable enough to protect privileged access.

Decision rule: If the SSH session can reach production systems or cloud control planes, treat PAM as part of a broader privileged access design, not as a standalone hardening step. In that case, scope credentials narrowly, prefer temporary access, and require logging that can be correlated with host and cloud activity.

Practitioner takeaway: The right goal is not “SSH with PAM enabled”, it is “SSH that cannot open a shell unless the policy engine is available, enforced, and observable.”

Related resources from NHI Mgmt Group

• How do you configure password policy requirements in an AWS Cognito user pool?
• How do you know whether AWS data controls are actually working?
• How do you know if AWS IAM controls are actually working?
• How do you know if PAM is actually protecting sensitive data?