等保整改里，为什么我只改 SSH 对应的 PAM 文件？
我对这件事印象很深，不是因为 PAM 多高级，而是因为它太容易把系统一起带崩。
当时是在一个很大的项目里做等保整改。
很多机器都按操作手册去改。
结果有些机器后来直接连不上了。
表面上看，大家改的都是：
- 密码复杂度
- 失败锁定
- 密码过期
- 历史密码
但真正动手时，很多人改到的已经不是单纯的 SSH 配置，而是 PAM 认证链路。
我这边虽然也改得不算漂亮，甚至有点乱，但最后没把自己锁死在机器外面，原因其实很简单：
我先把公钥登录配好了。
后面又出了第二个现场问题。
SSH 没炸，但 crontab 又不对了。
最后查下来，不是业务问题，而是权限和认证链路被带歪了。
这件事让我后来把原则收得很死：
改 PAM 前先配公钥。真要改，就只改 SSH 对应的 PAM 文件，不要顺手动全局 PAM。
一、PAM 到底是什么，为什么一改就容易带出别的问题？
PAM 可以先不要把它想得太学术。
你先把它理解成：
系统登录和认证入口前面的一层公共认证链。
很多入口都会经过它，比如：
sshdloginsusudopasswdcrond
所以 PAM 最麻烦的地方，不是“语法难”。
而是：
它不是单个功能配置，而是很多系统入口共用的一段认证链。
也就是说，你以为自己只是在改 SSH 登录规则，实际上可能改到的是：
- SSH 远程登录
- 本地控制台登录
susudo- 改密码
- 定时任务
这就是为什么很多人按手册一通改，最后出的问题却不是“SSH 某个参数没生效”，而是整个系统多个入口一起异常。
二、PAM 最少要怎么理解，才不容易乱？
PAM 你不用一开始就钻到每个模块参数里。
先记两个够用的结构。
1. PAM 是按服务入口拆的
你可以先看这些文件：
/etc/pam.d/sshd
/etc/pam.d/login
/etc/pam.d/su
/etc/pam.d/sudo
/etc/pam.d/passwd
/etc/pam.d/crond
它们不是一份总表，而是：
每个服务入口，都有自己对应的 PAM 入口文件。
所以如果你整改的目标是：
SSH 远程登录
那最直接对应的 PAM 入口就是：
/etc/pam.d/sshd
2. PAM 又会继续引用全局链路
真正危险的，往往不是 sshd 这个入口文件本身。
而是它里面常常还会继续引用一些全局文件，比如：
system-auth
password-auth
common-auth
common-password
common-account
common-session
这些文件一旦动了，影响的通常就不只是 SSH。
而是所有引用它们的服务一起受影响。
这就是为什么我后来对这件事的理解变成：
PAM 的风险不在“改没改 PAM”，而在“你改的是入口文件，还是全局链路”。
三、为什么我第一件事永远是先配公钥？
因为 PAM 改错的后果，不是“配置不优雅”。
而是：
密码明明对，但你进不去
如果你只有密码登录，那这种时候你很可能会把自己直接锁在服务器外面。
所以在动 PAM 之前，我最看重的不是写配置，而是先保命：
先确认公钥登录可用
当前 SSH 会话不要退出
这样就算密码认证链路改炸了，至少还有一条路能回去改。
这也是为什么同样一批整改，有些机器后来连不上，我这边虽然改得不算漂亮，但最后没炸。
不是因为我一开始就把 PAM 理得多透。
而是因为：
我先把回滚通道留住了。
四、后来为什么连 crontab 都会出问题？
这件事反而最能说明问题。
很多人以为：
我整改的是 SSH，最多影响 SSH。
但实际不是。
因为只要你动到了全局 PAM 链路，影响范围就未必停在 SSH。
后来 crontab 出问题，就是一个很典型的提醒：
你碰到的已经不是“SSH 的一个配置项”，而是系统认证和权限链的一部分。
有时候问题是模块配置不对。
有时候问题是引用关系不对。
有时候甚至是文件权限、属主、顺序错了，结果就会让本来不该受影响的入口也一起异常。
所以我后来对 PAM 的态度就更保守了。
不是不能改。
而是：
你必须先假设：一旦改扩散，受影响的绝对不只 SSH。
五、所以为什么我最后只改 /etc/pam.d/sshd？
因为整改目标如果就是：
SSH 远程登录
那我就希望把影响范围尽量限制在 SSH 入口本身。
也就是优先只碰：
/etc/pam.d/sshd
而不去顺手改：
system-auth
password-auth
common-auth
common-password
common-account
common-session
理由很现实：
sshd对应的是 SSH 入口，影响边界更清楚- 改完以后验证路径也更清楚
- 出问题时回滚成本更低
- 不容易误伤
su、sudo、passwd、crond
这件事的重点不是“技术上全局文件绝对不能动”。
而是：
只要你的整改目标没要求你重构整条系统认证链，那就不要主动把问题扩大。
六、这件事最后我只记两条
第一条：
改 PAM 前先配公钥。
别等改完才发现密码认证进不去，自己把自己锁在门外。
第二条：
如果整改目标是 SSH，就优先只改 /etc/pam.d/sshd。
别顺手去改全局 PAM 文件，更别觉得“反正手册里写了就一起改”。
因为 PAM 这种东西，真正危险的从来不是“语法不好看”。
而是：
你以为只改了 SSH，实际上改的是整条系统认证链。
最后一句
大项目等保整改里，PAM 最容易出事的不是“要不要改”，而是很多人照着手册一改就把影响范围放大了。我的经验最后只剩两条：先把公钥登录配好，给自己留回滚通道；如果目标只是 SSH 登录整改，就优先只改 /etc/pam.d/sshd，不要碰全局 PAM 链路。
