1. PAM基础与su命令的认证流程
Linux系统中的身份验证是个复杂但精妙的过程，而PAM（Pluggable Authentication Modules）就是背后的核心引擎。我第一次接触PAM配置时，看到/etc/pam.d目录下那些密密麻麻的文件也是一头雾水，直到有次服务器权限出了问题，才真正理解它的价值。
PAM的工作原理就像机场的多重安检流程。当用户执行su命令时，系统会按照/etc/pam.d/su文件中的配置顺序，依次调用不同的验证模块。每个模块就像一道安检门，有的检查身份（auth），有的核对登机牌（account），有的检查行李（session）。这种模块化设计让系统管理员可以灵活组合安全策略。
举个例子，默认配置中的auth sufficient pam_rootok.so就相当于VIP通道 - 如果检测到是root用户就直接放行。而auth substack system-auth则是把普通旅客引导到常规安检流程。我在实际运维中就遇到过因为误删system-auth引用导致所有用户都无法切换权限的情况。
2. 逐行拆解su配置文件
让我们用实际案例来解剖这个配置文件。以下是一个生产环境中经过安全加固的su配置示例：
#%PAM-1.0 auth required pam_env.so auth sufficient pam_rootok.so auth required pam_wheel.so use_uid auth substack system-auth auth include postloginpam_wheel.so模块特别值得注意。很多管理员不知道，简单地取消注释这行配置就能实现只允许wheel组成员使用su命令。我有次给客户做安全审计，发现他们服务器上20个用户都能随意su到root，就是缺了这个配置。
账户验证阶段的pam_succeed_if.so也是个实用模块。通过添加类似uid >= 1000这样的条件，可以防止普通用户越权。记得有次我在Ubuntu系统上发现这个模块的quiet参数被误删，导致系统日志里塞满了无关的认证消息。
3. 安全加固实战技巧
根据我处理过的安全事件，分享几个实用加固方案。首先是限制su的使用范围，这是最基本的防护：
# 只允许admin组使用su auth required pam_listfile.so item=group sense=allow file=/etc/su_allowed_groups其次是添加失败尝试限制，防止暴力破解。这个配置我曾在某金融客户的服务器上实施过：
# 5分钟内最多尝试3次 auth required pam_tally2.so deny=3 unlock_time=300日志审计也必不可少。建议在session部分添加：
# 记录所有su尝试 session required pam_loginuid.so session optional pam_audit.so有次排查入侵事件，就是靠这些日志发现攻击者尝试了数百次su切换操作。现在我的标准操作流程是：任何新服务器上线，第一件事就是配置这些PAM审计规则。
4. 常见问题排查指南
PAM配置出错时，系统表现往往令人困惑。我总结了几种典型症状和解决方法：
症状1：所有用户都无法su
- 检查点：system-auth的include语句
- 修复方案：
auth include system-auth确保路径正确
症状2：认证通过但环境变量丢失
- 检查点：pam_env.so模块
- 修复方案：确认/etc/security/pam_env.conf配置
症状3：root用户被要求输入密码
- 检查点：pam_rootok.so顺序
- 修复方案：确保它在其他auth模块之前
去年有家创业公司紧急求助，他们的开发服务器突然拒绝所有su请求。最后发现是有人误将required改成了requisite，导致任一模块失败就终止整个认证流程。这种错误在压力大的运维环境中其实很常见。
5. 高级配置与模块开发
对于有特殊需求的环境，可以考虑自定义PAM模块。我曾为某政府项目开发过一个基于硬件的双因素认证模块，核心逻辑就是hook进su的认证流程。
模块开发的基本步骤：
- 实现pam_sm_authenticate等接口函数
- 编译为.so文件放入/lib64/security/
- 在su配置中添加对应条目
测试时务必使用pam_exec.so先在shell脚本阶段验证逻辑，这是我踩过几次坑得出的经验。另外记得用pam_loginuid.so记录调试信息，这比直接查系统日志高效得多。
6. 不同发行版的差异处理
CentOS和Ubuntu的PAM配置有不少细微差别。比如在Ubuntu 20.04上，你会发现su配置默认启用了pam_umask：
# Ubuntu特有配置 session optional pam_umask.so而RHEL系则更依赖system-auth的集中管理。跨平台运维时，我习惯先用diff工具对比/etc/pam.d目录的差异。特别是当需要将安全策略从CentOS迁移到RockyLinux时，这些细节差异可能导致认证流程失效。
最近帮客户处理过一个典型案例：他们在AlmaLinux上复用了CentOS的PAM配置，结果发现sudo和su的行为不一致。问题根源在于两个发行版对pam_limits.so的处理方式不同。这种兼容性问题最好的预防方法是维护一个基准测试套件，在每次系统更新后自动验证关键认证流程。
