当登录请求发出时，链路开始运转
很多运维工程师都熟悉SSH登录、使用sudo提权，但未必清楚这两个日常操作背后，是一个高度模块化且环环相扣的身份控制链路。这个链路的核心，就是PAM（Pluggable Authentication Modules，可插拔认证模块）。理解这条链路，不仅是为了解决“为什么登录失败”或“为什么sudo没权限”这类具体问题，更是为了构建一套可预测、可审计、可防御的身份安全体系。
想象一个典型场景：你通过SSH客户端连接一台Linux服务器。输入用户名和密码后，系统不仅校验了密码，还可能检查了你的账户是否被锁定、是否允许在此时登录、甚至是否进行了二次验证。登录成功后，当你尝试执行sudo systemctl restart nginx时，系统又进行了一轮完全不同的权限校验。这两次看似独立的认证，实则共享着同一套底层认证框架——PAM，只是触发了链路中不同的节点和规则。
PAM：身份控制的中央调度器
PAM并非一个具体的工具，而是一个框架。它的设计哲学是将“认证逻辑”从应用程序（如sshd、login、sudo）中剥离出来。这意味着，开发SSH服务（openssh）的程序员不需要自己编写密码校验、账户状态检查的代码，只需要告诉系统“我要对用户进行认证”，PAM就会根据预设的剧本（配置文件）来执行。
PAM的配置文件位于/etc/pam.d/目录下，每个需要认证的服务都有一个对应的文件。这才是理解整个链路的关键入口。
$ ls /etc/pam.d/ | grep -E "(sshd|sudo|su|login)"
login
sshd
su
sudo
... 以/etc/pam.d/sshd文件为例，它定义了SSH服务认证的全流程。文件中的每一行都是一个独立的“检查点”，按顺序执行。每一行通常包含四个部分：模块类型 (type)、控制标志 (control)、模块路径 (module) 和 参数 (arguments)。
PAM的四种模块类型与工作逻辑
- auth (认证)：验证用户身份的真实性，例如核对密码、验证SSH密钥或动态令牌。
- account (账户管理)：检查账户是否可用，与身份无关。例如账户是否过期、是否允许在当前终端或时间段登录。
- password (密码管理)：专门处理与密码更新相关的任务。
- session (会话管理)：在用户登录成功或注销时设置环境，如记录日志、挂载目录、设置资源限制（ulimit）。
控制标志决定了模块的成功或失败如何影响整个认证流程：required失败会导致最终失败，但会继续执行后续模块（便于记录所有失败原因）；requisite失败则立即终止流程；sufficient成功则跳过同类型后续模块。
SSH登录：链路的第一段旅程
当你发起SSH连接时，sshd进程会加载/etc/pam.d/sshd配置文件。一个常见的配置片段可能如下所示：
auth substack password-auth
account required pam_nologin.so
account required pam_access.so
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_keyinit.so
session required pam_limits.so
session optional pam_motd.so
session include password-auth这个过程是：
- auth阶段：通过
substack password-auth调用通用密码认证栈，这里可能包含pam_unix.so（校验本地密码）或pam_sss.so（连接LDAP等中央认证源）。 - account阶段：
pam_nologin.so检查是否存在/etc/nologin文件以阻止非root登录；pam_access.so根据/etc/security/access.conf检查来源IP或用户名是否被允许。 - session阶段：设置会话的SELinux上下文、记录登录UID、应用
/etc/security/limits.conf中的资源限制、显示当日消息（MOTD）等。
这里的一个工程实践关键是：认证(auth)成功不代表登录(account)一定成功。即使密码正确，如果账户被锁或登录时间不被允许，依然会被拒绝。这实现了安全策略的层次化。
sudo提权：链路的权限检查点
用户成功登录后，在执行sudo命令时，触发了链路的另一个关键节点。sudo程序会读取/etc/pam.d/sudo配置文件。其流程与SSH类似，但侧重点不同。
sudo的PAM配置通常更简洁，因为它主要复用系统通用配置，并专注于执行前的二次验证（比如要求输入当前用户的密码，而不是目标root的密码）。更重要的是，sudo机制本身在PAM之上还有一层自己的策略规则——/etc/sudoers文件。
这就形成了双重检查：
- PAM层检查：确认“这个用户此刻是否允许进行身份切换操作”？这可能包括密码验证、会话限制等。
- sudoers策略层检查：确认“这个用户是否有权在特定主机上执行特定命令”？这是更细粒度的授权。
很多团队遇到的困惑是：明明在sudoers里配置了权限，用户却无法使用。问题往往出在PAM层，例如/etc/pam.d/sudo配置错误，或者PAM策略（如失败次数锁定）阻止了认证进行。
su切换：容易被忽略的链路旁路
su命令是另一条切换用户的路径，它同样受PAM控制（/etc/pam.d/su）。但与sudo不同，su默认要求知道目标用户的密码。这带来了安全风险：任何人理论上都可以不断尝试猜测root密码。
因此，生产环境中通常会对su命令进行严格限制。最经典的做法是启用pam_wheel.so模块，只允许wheel组成员使用su命令切换到root。
# /etc/pam.d/su 中的关键配置
auth required pam_wheel.so use_uid
同时，需要将可信用户加入wheel组：gpasswd -a username wheel。这个配置与sudo的%wheel ALL=(ALL) ALL授权形成了协同，将特权用户的管理集中到了wheel组。
关键节点加固：从理解到实践
理解了这条链路，安全加固就有了清晰的脉络。以下是一些关键节点的配置建议：
| 节点/文件 | 加固目的 | 实践配置示例 |
|---|---|---|
/etc/pam.d/sshd |
防止SSH暴力破解 | 添加 auth required pam_faillock.so deny=5 unlock_time=600 在auth部分，限制连续失败5次后锁定10分钟。 |
/etc/pam.d/sudo |
确保sudo操作可审计且安全 | 保持 @include common-auth，确保执行sudo前需验证用户密码。配合Defaults logfile in sudoers记录所有sudo操作。 |
/etc/pam.d/su |
严格限制su命令使用 | 启用 pam_wheel.so，并注释掉 auth sufficient pam_rootok.so（如果需要root切换也受控）。 |
/etc/security/access.conf |
基于来源的访问控制 | 添加规则如 -: ALL EXCEPT root (admin_user) : ALL EXCEPT 192.168.1.0/24，限制特定用户只能从内网IP登录。 |
/etc/sudoers |
最小权限原则 | 使用命令别名和用户别名，授予精确的命令路径，避免使用ALL。例如：webadmin ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/tail -f /var/log/nginx/*.log。 |
一个常见的配置陷阱
在修改/etc/pam.d/下的文件时，一个致命的错误是：在远程SSH会话中，错误配置了sshd或password-auth的PAM规则，导致所有认证被拒绝。更稳妥的做法是：
- 始终保持至少一个活跃的、已认证的SSH会话不退出，作为“救援通道”。
- 在另一个终端或会话中测试配置，例如使用
sudo或su来触发PAM认证，验证无误。 - 对于关键配置，可以先在测试环境验证。
总结：构建可控的身份边界
SSH、sudo和PAM构成的这条身份控制链路，是Linux系统安全的基石之一。它从“你是谁”（SSH+PAM认证）、“你是否被允许做这件事”（PAM账户检查+sudoers授权）两个维度构建了防御体系。
高效的运维和安全工作，不在于记住所有配置参数，而在于掌握这条链路的走向。当出现身份验证问题时，能够沿着“用户请求 -> 服务调用 -> PAM配置 -> 模块执行 -> 策略匹配”的路径进行排查。同样，在设计安全策略时，也应根据“入口控制（SSH）-> 会话管理（PAM session）-> 权限提升（sudo/su+PAM）”的层次来部署，实现纵深防御。
最终，这条链路的价值是赋予系统管理员一个可预测、可编排的身份边界。所有的访问和特权操作都在这个边界内清晰流转、记录和受控，这才是系统安全从被动响应走向主动设计的关键一步。
原创文章，作者：，如若转载，请注明出处：https://fczx.net/wiki/236