PAM Authentication Troubleshooting: Real-World Linux Server Failure Cases and Solutions

PAM (Pluggable Authentication Modules) is a highly efficient and flexible system-level authentication mechanism widely used in Linux server environments. This article presents real production故障 cases to analyze root causes and summarize best practices for PAM authentication.

Case 1: ulimit Configuration Not Taking Effect

After configuring resource limits (nofile) for a specific user (webedit) in /etc/security/limits.d/webapp.conf, the target process shows correct limits (/proc/{pid}/limits displays 500000), and switching users via 'su' also shows expected values. However, when SSH remote login is used, ulimit -n returns the default system value (1024).

Root cause: The SSH service was not compiled with PAM support. The system had an older SSH version that doesn't support the UsePAM option, causing the PAM session module (pam_limits.so) to never be invoked during SSH authentication, thus failing to load the limits configuration.

Why process limits were correct: The deployment platform uses sudo to switch users (opera -> webedit), which goes through PAM session phase and correctly loads pam_limits.so.

Case 2: Crontab Task Failures

Scheduled cron tasks suddenly failed with PAM authentication errors. Audit logs showed: 'PAM:setcred grantors=? acct="root" exe="/usr/sbin/crond" res=failed'.

Root cause: Security hardening added pam_faillock.so module with incorrect module order. The authfail rule was placed before pam_unix.so authentication, causing all users (including root) to be denied before proper credential verification.

Correct configuration requires proper module ordering:

auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=5 root_unlock_time=300
auth        sufficient    pam_unix.so nullok try_first_pass
auth        [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=5 root_unlock_time=300

Case 3: Custom PAM Authentication for Squid

Using pam_script module to implement dynamic username/password authentication for Squid proxy service. Users obtain credentials that rotate every 10 minutes, and PAM forwards authentication requests to a verification service.

Key Takeaways:

PAM configuration module order is critical - incorrect ordering can cause severe security issues or system failures

Security hardening with PAM requires thorough testing before production deployment

Common issues from improper PAM configuration include: SSH login failures, crontab execution failures, and ulimit modifications not taking effect