这套配置我在生产环境里前前后后调过好几轮踩过不少坑也拿着整改方案和测评机构反复对过口径。今天不聊虚的直接把我最终落地在银河麒麟高级服务器操作系统 V10 上的密码强度策略完整梳理一遍从等保核查项怎么理解、配置文件之间什么关系到每一步的配置命令和验证方法一次讲清楚。文章适合正在做等保整改、准备等保测评或者被单位安全基线要求搞得头疼的运维同学。尤其适合那些刚接手麒麟服务器、还搞不清密码策略到底该改哪个文件的兄弟。文章偏实操命令直接给但每一步我都会说清楚为什么这么改免得你稀里糊涂敲完一身冷汗。1. 等保测评中的密码策略到底在查什么1.1 把“等保要求”这句话翻译成人话等保2.0 三级里面和密码策略直接挂钩的主要集中在“安全计算环境”控制点下的身份鉴别部分原文大概是这样的应对登录的用户进行身份标识和鉴别身份标识具有唯一性身份鉴别信息具有复杂度要求并定期更换。应具有登录失败处理功能应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。当进行远程管理时应采取必要措施防止鉴别信息在网络传输过程中被窃听。翻译成我们运维要干的事其实就是四件事第一密码不能太简单而且到时间必须换。测评老师不会去数你的密码有多少位但会看你的配置文件里有没有长度、字符类别、有效期这些参数并且会实际用弱密码测试一遍看你系统拦不拦。第二连续输错密码要被锁住。比如连续错5次锁定30分钟同时控制台或SSH连接空闲超时要自动断开。这个在测评的时候通常会被实测所以不能只配置不生效更不能配了但错了没被检测出来。第三远程管理要用SSH等加密协议。不能开放明文Telnet之类的服务这是另外一个层面的要求但跟我们的密码登录强相关。第四所有可登录账户的密码都要定期更换对存量账户也要生效。很多兄弟只改了 /etc/login.defs 就以为完事了测一下发现老用户密码还是两年前的测评老师直接给记了一个不符合项。1.2 对应到麒麟系统上具体要动的文件有哪些麒麟KylinOS虽然有自己的安全中心等图形化管理工具但等保整改大多时候还是命令行效率高、可复现、好截图。和生产环境相关的核心配置文件主要有这几个/etc/login.defs控制密码有效期、最短修改天数、过期提醒天数。/etc/security/pwquality.conf密码复杂度比如长度、字符类别、连续重复字符限制。/etc/pam.d/system-auth 和 /etc/pam.d/password-authPAM认证堆栈负责把复杂度、失败锁定、历史密码这些模块串起来。/etc/security/faillock.conf如果系统PAM使用faillock模块这里可以集中配登录失败锁定参数。/etc/ssh/sshd_configSSH空闲超时、是否允许root远程登录等。/etc/profile.d/ 下的脚本配置会话空闲超时TMOUT。这些文件每个管一摊事但也互相配合。很多人改完某一个文件就以为配置完成了结果测评老师换个角度一测就露馅。真正稳妥的做法是分层防御有效期靠login.defs复杂度靠pam_pwquality失败锁定靠pam_faillock历史密码靠pam_pwhistory空闲超时靠sshd和profile最后再手动批量处理存量账户。2. 动手之前必须先搞清楚的三件事2.1 先确认系统版本和PAM管理方式同样叫麒麟V10不同小版本、不同架构x86/ARM/飞腾/鲲鹏之间PAM的配置可能略有差别。我建议动手前先跑两个命令cat /etc/kylin-release lsb_release -a接着看PAM是否被authselect接管authselect current如果输出类似“Profile ID: ...”说明系统启用了authselect管理PAM配置那你直接改 /etc/pam.d/system-auth下次authselect应用配置或系统更新时可能会被覆盖。但根据我的实际接触绝大多数银河麒麟服务器版 V10 的默认状态是传统PAM文件管理方式直接改文件就能生效。不过稳妥起见改之前先备份一份这个操作绝对不能省。cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak.$(date %F) cp /etc/pam.d/password-auth /etc/pam.d/password-auth.bak.$(date %F)2.2 明确你要满足的密码强度基线等保标准本身没有把密码位数一口咬死但测评机构通常会参考国家或行业的安全基线常见的做法是密码长度至少9位部分行业要求至少10位或12位。包含大写字母、小写字母、数字、特殊字符中至少三类。密码有效期不超过90天最短使用期限不少于7天过期前14天提醒。密码历史记录不少于5次也就是不能重复使用最近5次用过的密码。连续登录失败5次锁定30分钟。有的测评机构会要求“四类字符全包含”这也没问题我们在pwquality里都配强制包含就行宁严勿松。我自己在实际项目里采用的基线是长度12位四类字符各至少一个不允许连续3个相同字符有效期90天最短7天提醒14天历史5次失败5次锁30分钟。这个强度在多数等保三级测评里都能过而且不会因为各种自定义场景被翻出来打补丁。2.3 配置顺序也很关键我的建议是先从“不影响登录的独立配置文件”开始最后再改PAM堆栈。因为PAM文件一旦配错可能导致所有用户无法登录。通常按这个顺序来先改 /etc/login.defs这是最安全的。再改 /etc/security/pwquality.conf测试密码复杂度。然后改 /etc/security/faillock.conf测试失败锁定。接着改 /etc/pam.d/system-auth 和 password-auth把历史密码、复杂度、锁定串起来。再改SSH超时和TMOUT。最后批量处理存量用户。每一步改完都建议先验证生效再进入下一步不要一口气全改完再排查否则出了问题很难定位。3. 手把手配置六步完成密码策略整改3.1 第一步设置密码有效期与最短修改周期这个相对简单编辑 /etc/login.defs把下面几项改掉或确认vi /etc/login.defs找到并修改PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12 PASS_WARN_AGE 14解释一下这几个参数的意思PASS_MAX_DAYS 90密码最长使用90天到期强制修改。PASS_MIN_DAYS 7修改密码后至少7天内不能再改防止用户反复改密码绕开历史记录检查。PASS_MIN_LEN 12这是给一些老程序的兜底配置实际上最终拦截靠的是pam_pwquality但这里也建议同步改成12。PASS_WARN_AGE 14密码过期前14天开始提醒用户。需要注意login.defs 里这些参数主要影响“新建用户”的初始默认值。对已经存在的用户不会立刻改变他们的密码过期时间。所以第3.6节里必须用chage批量处理存量账户这个地方等保测评老师是必查的。3.2 第二步配置密码复杂度在麒麟V10中密码复杂度的核心控制者是pam_pwquality模块它的独立配置文件是 /etc/security/pwquality.conf。建议这样配置vi /etc/security/pwquality.conf写入或取消注释以下内容minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1 minclass 3 maxrepeat 3逐个说明minlen 12密码最小长度12位。dcredit -1数字至少1位。负数表示强制要求0表示不要求但添加可加分正数表示最多可减免的分数。所以这里必须用负数。ucredit -1大写字母至少1位。lcredit -1小写字母至少1位。ocredit -1特殊字符至少1位。minclass 3字符类别至少3种。这一项其实在四个 -1 都配好的情况下有点重复但保留它可以应对有些测评机构只看minclass的情况属于双保险。maxrepeat 3禁止出现连续3个及以上相同字符比如“aaa”这样的。需要解释一个容易踩坑的点minlen并不是简单的中文字符个数。它在计算时会给不同字符类型分配不同的权重大致类似“长度总分密码位数各类字符带来的加分”所以配置了四类符号必须包含后实际可接受的最短密码往往会超过12位这是正常的不要以为模块算错了。如果你发现测试时“123Aa!#”这种长度已经12位的密码还是被拒大概率就是minlen计算规则在起作用想宽松些就把minlen降到10或11。确认PAM已经加载了pam_pwquality后这个文件就会生效。检查 /etc/pam.d/system-auth 的password段确认有类似下面这行password requisite pam_pwquality.so try_first_pass local_users_only retry3 enforce_for_root authtok_type如果缺少就手动加上。其中retry3允许用户输入错误后重试3次超过再报错。enforce_for_rootroot用户修改密码时也要受复杂度限制。这个参数我建议必须加否则测评老师用root测试弱密码系统直接放行就尴尬了。同理检查 /etc/pam.d/password-auth两边的配置要保持一致因为SSH和本地登录走的PAM服务文件不一样只改一个容易出现“SSH上检查很严本地控制台却松得很”的问题。3.3 第三步开启登录失败锁定麒麟V10默认使用的PAM锁定模块通常是pam_faillock对应配置文件是 /etc/security/faillock.conf。先看这个文件是否存在ls -l /etc/security/faillock.conf如果存在推荐在这里集中配置方便查看和维护。写入如下内容deny 5 unlock_time 1800 # even_deny_root # silent # audit解释一下deny 5连续5次认证失败后锁定该账户。unlock_time 1800锁定30分钟后自动解锁单位是秒。even_deny_root默认被注释表示root账户不参与锁定。我建议这行先保持注释状态原因在“常见问题”那节详细讲。如果测评要求所有账户包括root都锁再取消注释但前提是你必须有控制台或管理口备用。silent默认注释保持不开启否则失败时不会提示用户账户被锁原因。audit默认注释保持不开启避免记录过多认证信息到日志。如果系统里没有 faillock.conf 文件就需要直接在PAM配置中加参数。编辑 /etc/pam.d/system-auth确保auth段按下面这种结构组织参数直接写在preauth和authfail两行上auth required pam_env.so auth required pam_faillock.so preauth deny5 unlock_time1800 auth sufficient pam_unix.so try_first_pass auth [defaultdie] pam_faillock.so authfail deny5 unlock_time1800 auth sufficient pam_faillock.so authsucc auth required pam_deny.so这里面的逻辑是preauth先检查这个账户当前是否处于锁定状态如果锁了就直接拒绝然后走pam_unix验证用户名密码如果密码验证失败authfail就记录一次失败次数如果密码验证成功authsucc就把失败计数清零。这种结构能保证锁定期内即使输入正确密码也进不来。需要注意的是因为我在利用faillock.conf中的配置PAM行上可以不重复写deny和unlock_time。但如果你不确定faillock.conf是否被正确读取直接在PAM行上写参数是最保险的。两者同时存在时PAM行上的参数优先级更高。另外也要同步修改 /etc/pam.d/password-auth保持同样的结构否则用密码认证的服务行为会不一致。3.4 第四步配置密码历史记录等保要求密码不能重复使用太多次在Linux里一般通过pam_pwhistory模块实现。编辑 /etc/pam.d/system-auth在password段添加一行password required pam_pwhistory.so remember5 use_authtok注意位置需要放在pam_pwquality之前、pam_unix之前。我建议的password段完整结构参考如下password required pam_pwhistory.so remember5 use_authtok password requisite pam_pwquality.so try_first_pass local_users_only retry3 enforce_for_root authtok_type password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so同样在 /etc/pam.d/password-auth 里保持一样的配置。这里有个容易出细节问题的地方历史密码记录默认存放在 /etc/security/opasswd你配置好之后第一次有用户修改密码时才会生成或更新这个文件。检查历史记录是否生效的简单方法是尝试把一个用户密码改成和最近一次一模一样的旧密码如果系统提示“密码已经被使用过”或“密码重用了”说明生效。3.5 第五步配置会话空闲超时和SSH超时这部分对应等保里“当登录连接超时自动退出”的要求。先配置用户会话空闲超时TMOUT在 /etc/profile.d/ 下创建一个脚本cat /etc/profile.d/tmout.sh EOF readonly TMOUT600 export TMOUT EOF这里用readonly的原因是防止用户在自己的shell里把超时变量改掉。TMOUT600 表示用户在终端里连续600秒10分钟没有任何操作会话就被自动退出。这个时间可以根据单位要求调整常见的有300秒和600秒。注意这个配置对已经登录的会话不会立即生效需要用户重新登录一次。如果你自己的SSH会话正好开着别原地等着它踢你重开一个窗口顺便测试下是否生效。接着配置SSH层面的空闲超时。编辑 /etc/ssh/sshd_configvi /etc/ssh/sshd_config找到或添加ClientAliveInterval 300 ClientAliveCountMax 0解释一下ClientAliveInterval 300服务器每300秒向客户端发送一个保活消息等待客户端响应。ClientAliveCountMax 0如果客户端连续0次即一次未响应立即断开连接。合起来的实际效果就是5分钟没有数据交互就断开。不要把ClientAliveCountMax设置得太大比如默认的3那样会拖到15分钟以上才断测评时测不出来。修改完成后重启SSH服务systemctl restart sshd重启SSH服务前一定要确认你当前会话不依赖于一个未保存的配置否则重启可能导致连接闪断。稳妥起见可以先用sshd -t检查配置语法sshd -t如果没有任何输出说明配置语法正确。再补充一个SSH层面的加固项。如果你们运维习惯用密码登录那就保持PasswordAuthentication yes靠上面的PAM策略做防护。如果单位已经强制用密钥登录可以顺手把密码登录关掉PasswordAuthentication no PermitRootLogin prohibit-password这样root远程只能用密钥登录密码策略性风险进一步降低。但这一步改之前必须确认所有管理员手上都有可用的私钥否则会把自己锁在门外。我见过不止一次因为关密码登录导致整个团队都进不去服务器的惨案。3.6 第六步批量处理存量用户很多系统上线时间久里面几十个账户的密码可能已经两年没动过了。等保测评时检查“定期更换”要求不会只看新建用户而是抽查所有可登录账户的chage信息。批量查看所有可登录用户的密码过期时间for user in $(awk -F: $7 ~ /(\/bin\/bash|\/bin\/sh)$/ {print $1} /etc/passwd); do echo $user chage -l $user | grep -E Password expires|密码过期 done如果发现有大量的“never”或早于90天的旧日期就要批量更新策略。执行下面的命令对所有可登录用户设置密码最长90天、最短7天、提前14天提醒for user in $(awk -F: $7 ~ /(\/bin\/bash|\/bin\/sh)$/ {print $1} /etc/passwd); do chage -M 90 -m 7 -W 14 $user done再啰嗦一句这个循环只处理shell为/bin/bash、/bin/sh等可登录账户的用户系统自带的服务账户nologin不去动它避免影响系统服务或守护进程的管理。有些等保同学会图省事直接对全量用户跑chage -M 90不要这么干系统账户强行设密码期限很可能给后面运维埋雷。批量设置完以后重新执行一遍查看命令确认每个账户都已经变成90天、7天、14天的状态这个步骤在测评整改报告里截图非常有用。还有一个顺手项检查是否存在空密码账户防止被当成严重漏洞awk -F: ($2){print $1} /etc/shadow如果这条命令有输出说明存在没有口令的账户必须立刻处理。正常情况下没有输出。4. 怎样证明策略已经生效自查与验证流程4.1 配置文件层面的自查配置完成后不要直接提交整改报告先自己检查一遍配置是否落到正确的位置。把下面这些命令跑一遍输出留档grep -E PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN|PASS_WARN_AGE /etc/login.defs grep -E minlen|dcredit|ucredit|lcredit|ocredit|minclass|maxrepeat /etc/security/pwquality.conf grep -E deny|unlock_time /etc/security/faillock.conf grep -E pam_pwquality|pam_pwhistory|pam_faillock /etc/pam.d/system-auth grep -E ClientAliveInterval|ClientAliveCountMax|PasswordAuthentication|PermitRootLogin /etc/ssh/sshd_config如果这些输出都是你预期中的值配置文件这关基本就稳了。4.2 实测验证密码复杂度光看配置还不够测评老师一定会动手测。我们要在自己可控的环境里先测一遍避免到现场翻车。找一个非root的普通测试用户比如testuser用root切换到该用户尝试修改密码passwd testuser然后输入一个弱密码比如“123456”或者“password”观察系统的反馈。正常情况下应该会提示密码不符合要求并被反复要求重新输入直到超过retry次数后报错。再试一个符合要求的强密码例如“Kylin2024Admin”这次应该能成功修改。如果强密码也报错大概率是密码长度或字符类别参数设置过于严格回头检查pwquality.conf里的取值适当放宽。这个“弱密码被拒、强密码通过”的测试过程我强烈建议用script命令记录会话输出留着当整改证据script -q /tmp/password-test.log passwd testuser exit测评老师看证据时你直接甩一份真实执行记录比空口说“我配置了”有力得多。4.3 实测验证登录失败锁定这一步同样要提前做并且要在非关键窗口执行避免触发告警或影响正在使用该服务器的同事。可以这样做比如故意连续输错testuser的密码5次su - testuser # 连续5次输入错误密码或者通过SSH尝试登录每次都输错密码ssh testuserlocalhost第5次失败后再尝试用正确密码登录系统应该提示账户已被锁定无法登录。此时可以用faillock命令查看锁定状态faillock --user testuser输出里会显示此次失败尝试的来源和失败次数。测试完后需要立即解锁因为测试用户可能还要继续用faillock --user testuser --reset再强调一遍这个测试最好别拿root账户做尤其在开启even_deny_root的情况下否则锁完自己都没法进入系统。4.4 测评前的一页纸自检清单根据我多次配合测评的经验整理一份自查清单如下建议打成表格贴在运维文档里检查项期望结果命令密码最长有效期90天chage -l testuser密码最短修改周期7天chage -l testuser密码过期提醒14天chage -l testuser密码长度至少12位grep minlen /etc/security/pwquality.conf包含字符类别四类各至少1个grep dcredit /etc/security/pwquality.conf连续相同字符限制不超过3个grep maxrepeat /etc/security/pwquality.conf登录失败锁定5次锁定30分钟grep deny /etc/security/faillock.conf密码历史记录最近5次不可重复grep pam_pwhistory /etc/pam.d/system-authSSH空闲超时5分钟断开grep ClientAliveInterval /etc/ssh/sshd_config会话空闲超时10分钟退出cat /etc/profile.d/tmout.sh空密码账户无输出awk -F: ($2){print $1} /etc/shadow测评现场老师基本上就按这些点抽查你提前把输出结果准备在当前目录下有的老师会让你现场执行看一遍所以命令要熟练别到现场翻笔记。5. 常见问题与避坑经验实录5.1 配置都改了弱密码还是能设置这个我遇到过很多次先别怀疑自己配置错了按下面顺序排查第一确认是否同时修改了system-auth和password-auth两个PAM文件。SSH的密码认证走的是password-auth本地登录走的是system-auth你只改其中一个就会出现“本地改不了弱密码SSH却能改”的情况测评老师往往就是用SSH登录后测试的当场翻车。第二检查pam_pwquality模块是否真的被调用。有的系统里system-auth里这行被注释了或者放在了错误的位置。用pam_listfile或者直接cat /etc/pam.d/system-auth检查。第三如果你用的是图形化界面里的“设置-用户”去改密码有些桌面环境不一定走完整的PAM密码复杂度检查。所以验证时尽量用passwd命令这才是测评老师最常用的路径。图形界面能不能拦住弱密码要不要拦截得看你们单位自己的要求。第四如果系统启用了authselect管理你手工改的PAM文件可能在authselect执行后被覆盖这种情况下要考虑用authselect的自定义profile或者在独立配置文件中落地。区分方法就是之前说的authselect current。5.2 登录失败锁定模块配错可能导致谁都登不进去这是我刚学PAM配置时踩过最痛的坑。当时我在system-auth里同时保留了pam_tally2和pam_faillock两套配置结果在某次测试时所有人都登录不进去了因为两个模块都在记录和判定失败次数把计数逻辑彻底搞乱了。新版麒麟系统默认用的是pam_faillock老的教程里常见的是pam_tally2。两个模块不能同时启用二选一并且要保证PAM堆栈里同一模块相关的preauth、authfail、authsucc顺序正确。如果不小心把自己锁外面了并且系统里设置了even_deny_root就非常被动了。唯一的办法是通过物理控制台、管理口、单用户模式或者重启进入紧急模式去清理锁定文件。faillock的计数文件在 /var/run/faillock/ 目录下root用户如果有权限可以手动删除对应文件rm -f /var/run/faillock/username所以再次强调改PAM文件前备份测试时换一个非关键用户始终保持一个当前root会话不要关掉。5.3 root账户到底要不要参与失败锁定这个问题我在不同单位遇到过截然不同的要求。有的测评老师说root也是账户必须锁定有的安全管理员说root一锁风险太大hold不住。我的建议是如果你们有带外管理口、物理控制台或者KVMroot可以参与锁定也就是启用even_deny_root这样测评最严格的要求也满足。如果你们只有SSH远程这一条路强烈建议不要启用even_deny_root否则一次误操作就把自己关在门外到时候恢复的成本远超等保整改带来的收益。折中方案是把SSH的PermitRootLogin设为prohibit-password关闭root的密码远程登录然后启用even_deny_rootroot即便在本地被锁也能通过管理员的普通账户sudo进入影响可控。5.4 密码历史记录不生效配置了pam_pwhistory但修改密码时还是能重复使用旧密码排查顺序如下先看 /etc/security/opasswd 这个文件是否存在。如果目录存在但文件不存在第一次修改密码时应该会自动创建。如果完全没有这个文件说明模块根本没被调用。再检查pam_pwhistory那一行放在哪里。如果放在了pam_unix之后历史检查可能不会生效因为pam_unix已经先完成了密码更新。要确保pam_pwhistory在password段比较靠前的位置比如我前面给的结构里放在pam_pwquality和pam_unix之前。最后查看 /etc/pam.d/password-auth 是否也配置了如果只改了system-authSSH密码修改这条路径就不会生效。还有一个不起眼但很常见的坑有些系统在password段用的是pam_unix.so并带remember参数同时也手动加了pam_pwhistory两套机制同时存在可能造成历史密码被记录两次行为看着正常但方向不统一。建议只用其中一种首选pam_pwhistory更直观。5.5 SSH密钥登录和密码策略的关系这里要澄清一个容易被人误解的点密码策略只对“用密码认证”这个动作生效。如果某个用户配置了SSH密钥并且sshd开启了PubkeyAuthentication那这个用户通过密钥登录时是不需要输入密码的PAM的复杂度、锁定策略都不会拦截。等保测评老师通常不会因为你有密钥登录就判定密码策略不符合他们会看密码登录这个通道是否被正确加固。所以你可以保持密码和密钥共存但前提是密码本身体系要强。如果你想彻底减少暴力破解风险就直接禁用密码登录只保留密钥但这时候密码策略更多是用来防本地控制台登录和sudo等场景。如果决定关密码登录请确保所有管理员密钥可用并至少保留一个带外通道或者让一名运维在机房待命再执行systemctl restart sshd我知道这句话已经说了三遍但还是得说因为真的有人会在重启后崩溃。5.6 修改 PAM 文件后是否需要重启服务PAM配置是动态读取的改完文件后新登录的连接立刻生效已经登录的会话不受影响。所以不需要重启sshd也不需要重启服务器。但SSH的配置文件修改后必须重启sshd才会生效。TMOUT配置需要新登录会话才生效。如果你在排查问题时发现改了PAM但系统好像还是老行为可以先看看有没有同时改到位再考虑是不是有缓存或其他模块在兜底比如有的系统会同时加载 /etc/pam.d/system-auth-ac注意同步。5.7 关于图形化工具与命令行的取舍麒麟系统自带的安全中心或类似图形工具理论上可以配置部分密码策略。但在等保整改场景下我更推荐命令行配置。原因很简单第一命令行的配置路径可重现一条命令能搞定的事情不用在图形界面点半天。 第二等保整改报告需要截图或脚本留痕命令行输出比图形界面截图更清晰也更好归档。 第三服务器版往往没装图形环境即使装了运维习惯也以命令行为主覆盖面更广。当然如果你们单位有统一的安全管控平台可以通过平台下发基线配置那就按平台的套路来命令行方案可以作为应急和复查手段并存。6. 最后再分享一点我的实际经验这套配置我在麒麟V10上前后调整过三轮最终形成了文章里的这套方案。整个过程让我最深刻的体会是等保整改不是把参数“配置上”就完了而是要保证每一项要求都有“活证据”也就是现场演示能通过、日志和截图能留痕。所以我的建议是每次改完配置都顺手把验证命令执行一遍把输出保存到整改报告里。比如弱密码被拒绝的终端输出、faillock的锁定记录、批量chage后的用户清单这些都是测评沟通时的硬通货。另外就是密码策略这东西过严会影响运维效率过松又过不了测评。建议先按文中的中等偏严级别配置遇到特殊账户和业务场景再单独豁免。所谓“特殊豁免”不是嘴上说说要在整改说明里写清楚原因比如某些自动化程序使用的服务账户无法90天改密码那就用密钥认证替代或设置专用策略并留存审批记录别等着测评组来质疑。最后再送一个实用小技巧在做任何PAM相关变更前一定要确保当前SSH会话不被中断再开一个新窗口测试登录。如果新窗口能正常登录再去动下一个文件如果新窗口登录失败立刻用备份恢复不要慌更不要一根筋地在断了连接的情况下瞎猜。多留一条后路比任何技巧都重要。 
长河君 · 2026/10/6 3:28:02 · 阅读 1.2k 银河麒麟V10等保整改：密码策略与PAM配置实战
这套配置我在生产环境里前前后后调过好几轮踩过不少坑也拿着整改方案和测评机构反复对过口径。今天不聊虚的直接把我最终落地在银河麒麟高级服务器操作系统 V10 上的密码强度策略完整梳理一遍从等保核查项怎么理解、配置文件之间什么关系到每一步的配置命令和验证方法一次讲清楚。文章适合正在做等保整改、准备等保测评或者被单位安全基线要求搞得头疼的运维同学。尤其适合那些刚接手麒麟服务器、还搞不清密码策略到底该改哪个文件的兄弟。文章偏实操命令直接给但每一步我都会说清楚为什么这么改免得你稀里糊涂敲完一身冷汗。1. 等保测评中的密码策略到底在查什么1.1 把“等保要求”这句话翻译成人话等保2.0 三级里面和密码策略直接挂钩的主要集中在“安全计算环境”控制点下的身份鉴别部分原文大概是这样的应对登录的用户进行身份标识和鉴别身份标识具有唯一性身份鉴别信息具有复杂度要求并定期更换。应具有登录失败处理功能应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。当进行远程管理时应采取必要措施防止鉴别信息在网络传输过程中被窃听。翻译成我们运维要干的事其实就是四件事第一密码不能太简单而且到时间必须换。测评老师不会去数你的密码有多少位但会看你的配置文件里有没有长度、字符类别、有效期这些参数并且会实际用弱密码测试一遍看你系统拦不拦。第二连续输错密码要被锁住。比如连续错5次锁定30分钟同时控制台或SSH连接空闲超时要自动断开。这个在测评的时候通常会被实测所以不能只配置不生效更不能配了但错了没被检测出来。第三远程管理要用SSH等加密协议。不能开放明文Telnet之类的服务这是另外一个层面的要求但跟我们的密码登录强相关。第四所有可登录账户的密码都要定期更换对存量账户也要生效。很多兄弟只改了 /etc/login.defs 就以为完事了测一下发现老用户密码还是两年前的测评老师直接给记了一个不符合项。1.2 对应到麒麟系统上具体要动的文件有哪些麒麟KylinOS虽然有自己的安全中心等图形化管理工具但等保整改大多时候还是命令行效率高、可复现、好截图。和生产环境相关的核心配置文件主要有这几个/etc/login.defs控制密码有效期、最短修改天数、过期提醒天数。/etc/security/pwquality.conf密码复杂度比如长度、字符类别、连续重复字符限制。/etc/pam.d/system-auth 和 /etc/pam.d/password-authPAM认证堆栈负责把复杂度、失败锁定、历史密码这些模块串起来。/etc/security/faillock.conf如果系统PAM使用faillock模块这里可以集中配登录失败锁定参数。/etc/ssh/sshd_configSSH空闲超时、是否允许root远程登录等。/etc/profile.d/ 下的脚本配置会话空闲超时TMOUT。这些文件每个管一摊事但也互相配合。很多人改完某一个文件就以为配置完成了结果测评老师换个角度一测就露馅。真正稳妥的做法是分层防御有效期靠login.defs复杂度靠pam_pwquality失败锁定靠pam_faillock历史密码靠pam_pwhistory空闲超时靠sshd和profile最后再手动批量处理存量账户。2. 动手之前必须先搞清楚的三件事2.1 先确认系统版本和PAM管理方式同样叫麒麟V10不同小版本、不同架构x86/ARM/飞腾/鲲鹏之间PAM的配置可能略有差别。我建议动手前先跑两个命令cat /etc/kylin-release lsb_release -a接着看PAM是否被authselect接管authselect current如果输出类似“Profile ID: ...”说明系统启用了authselect管理PAM配置那你直接改 /etc/pam.d/system-auth下次authselect应用配置或系统更新时可能会被覆盖。但根据我的实际接触绝大多数银河麒麟服务器版 V10 的默认状态是传统PAM文件管理方式直接改文件就能生效。不过稳妥起见改之前先备份一份这个操作绝对不能省。cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak.$(date %F) cp /etc/pam.d/password-auth /etc/pam.d/password-auth.bak.$(date %F)2.2 明确你要满足的密码强度基线等保标准本身没有把密码位数一口咬死但测评机构通常会参考国家或行业的安全基线常见的做法是密码长度至少9位部分行业要求至少10位或12位。包含大写字母、小写字母、数字、特殊字符中至少三类。密码有效期不超过90天最短使用期限不少于7天过期前14天提醒。密码历史记录不少于5次也就是不能重复使用最近5次用过的密码。连续登录失败5次锁定30分钟。有的测评机构会要求“四类字符全包含”这也没问题我们在pwquality里都配强制包含就行宁严勿松。我自己在实际项目里采用的基线是长度12位四类字符各至少一个不允许连续3个相同字符有效期90天最短7天提醒14天历史5次失败5次锁30分钟。这个强度在多数等保三级测评里都能过而且不会因为各种自定义场景被翻出来打补丁。2.3 配置顺序也很关键我的建议是先从“不影响登录的独立配置文件”开始最后再改PAM堆栈。因为PAM文件一旦配错可能导致所有用户无法登录。通常按这个顺序来先改 /etc/login.defs这是最安全的。再改 /etc/security/pwquality.conf测试密码复杂度。然后改 /etc/security/faillock.conf测试失败锁定。接着改 /etc/pam.d/system-auth 和 password-auth把历史密码、复杂度、锁定串起来。再改SSH超时和TMOUT。最后批量处理存量用户。每一步改完都建议先验证生效再进入下一步不要一口气全改完再排查否则出了问题很难定位。3. 手把手配置六步完成密码策略整改3.1 第一步设置密码有效期与最短修改周期这个相对简单编辑 /etc/login.defs把下面几项改掉或确认vi /etc/login.defs找到并修改PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12 PASS_WARN_AGE 14解释一下这几个参数的意思PASS_MAX_DAYS 90密码最长使用90天到期强制修改。PASS_MIN_DAYS 7修改密码后至少7天内不能再改防止用户反复改密码绕开历史记录检查。PASS_MIN_LEN 12这是给一些老程序的兜底配置实际上最终拦截靠的是pam_pwquality但这里也建议同步改成12。PASS_WARN_AGE 14密码过期前14天开始提醒用户。需要注意login.defs 里这些参数主要影响“新建用户”的初始默认值。对已经存在的用户不会立刻改变他们的密码过期时间。所以第3.6节里必须用chage批量处理存量账户这个地方等保测评老师是必查的。3.2 第二步配置密码复杂度在麒麟V10中密码复杂度的核心控制者是pam_pwquality模块它的独立配置文件是 /etc/security/pwquality.conf。建议这样配置vi /etc/security/pwquality.conf写入或取消注释以下内容minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1 minclass 3 maxrepeat 3逐个说明minlen 12密码最小长度12位。dcredit -1数字至少1位。负数表示强制要求0表示不要求但添加可加分正数表示最多可减免的分数。所以这里必须用负数。ucredit -1大写字母至少1位。lcredit -1小写字母至少1位。ocredit -1特殊字符至少1位。minclass 3字符类别至少3种。这一项其实在四个 -1 都配好的情况下有点重复但保留它可以应对有些测评机构只看minclass的情况属于双保险。maxrepeat 3禁止出现连续3个及以上相同字符比如“aaa”这样的。需要解释一个容易踩坑的点minlen并不是简单的中文字符个数。它在计算时会给不同字符类型分配不同的权重大致类似“长度总分密码位数各类字符带来的加分”所以配置了四类符号必须包含后实际可接受的最短密码往往会超过12位这是正常的不要以为模块算错了。如果你发现测试时“123Aa!#”这种长度已经12位的密码还是被拒大概率就是minlen计算规则在起作用想宽松些就把minlen降到10或11。确认PAM已经加载了pam_pwquality后这个文件就会生效。检查 /etc/pam.d/system-auth 的password段确认有类似下面这行password requisite pam_pwquality.so try_first_pass local_users_only retry3 enforce_for_root authtok_type如果缺少就手动加上。其中retry3允许用户输入错误后重试3次超过再报错。enforce_for_rootroot用户修改密码时也要受复杂度限制。这个参数我建议必须加否则测评老师用root测试弱密码系统直接放行就尴尬了。同理检查 /etc/pam.d/password-auth两边的配置要保持一致因为SSH和本地登录走的PAM服务文件不一样只改一个容易出现“SSH上检查很严本地控制台却松得很”的问题。3.3 第三步开启登录失败锁定麒麟V10默认使用的PAM锁定模块通常是pam_faillock对应配置文件是 /etc/security/faillock.conf。先看这个文件是否存在ls -l /etc/security/faillock.conf如果存在推荐在这里集中配置方便查看和维护。写入如下内容deny 5 unlock_time 1800 # even_deny_root # silent # audit解释一下deny 5连续5次认证失败后锁定该账户。unlock_time 1800锁定30分钟后自动解锁单位是秒。even_deny_root默认被注释表示root账户不参与锁定。我建议这行先保持注释状态原因在“常见问题”那节详细讲。如果测评要求所有账户包括root都锁再取消注释但前提是你必须有控制台或管理口备用。silent默认注释保持不开启否则失败时不会提示用户账户被锁原因。audit默认注释保持不开启避免记录过多认证信息到日志。如果系统里没有 faillock.conf 文件就需要直接在PAM配置中加参数。编辑 /etc/pam.d/system-auth确保auth段按下面这种结构组织参数直接写在preauth和authfail两行上auth required pam_env.so auth required pam_faillock.so preauth deny5 unlock_time1800 auth sufficient pam_unix.so try_first_pass auth [defaultdie] pam_faillock.so authfail deny5 unlock_time1800 auth sufficient pam_faillock.so authsucc auth required pam_deny.so这里面的逻辑是preauth先检查这个账户当前是否处于锁定状态如果锁了就直接拒绝然后走pam_unix验证用户名密码如果密码验证失败authfail就记录一次失败次数如果密码验证成功authsucc就把失败计数清零。这种结构能保证锁定期内即使输入正确密码也进不来。需要注意的是因为我在利用faillock.conf中的配置PAM行上可以不重复写deny和unlock_time。但如果你不确定faillock.conf是否被正确读取直接在PAM行上写参数是最保险的。两者同时存在时PAM行上的参数优先级更高。另外也要同步修改 /etc/pam.d/password-auth保持同样的结构否则用密码认证的服务行为会不一致。3.4 第四步配置密码历史记录等保要求密码不能重复使用太多次在Linux里一般通过pam_pwhistory模块实现。编辑 /etc/pam.d/system-auth在password段添加一行password required pam_pwhistory.so remember5 use_authtok注意位置需要放在pam_pwquality之前、pam_unix之前。我建议的password段完整结构参考如下password required pam_pwhistory.so remember5 use_authtok password requisite pam_pwquality.so try_first_pass local_users_only retry3 enforce_for_root authtok_type password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so同样在 /etc/pam.d/password-auth 里保持一样的配置。这里有个容易出细节问题的地方历史密码记录默认存放在 /etc/security/opasswd你配置好之后第一次有用户修改密码时才会生成或更新这个文件。检查历史记录是否生效的简单方法是尝试把一个用户密码改成和最近一次一模一样的旧密码如果系统提示“密码已经被使用过”或“密码重用了”说明生效。3.5 第五步配置会话空闲超时和SSH超时这部分对应等保里“当登录连接超时自动退出”的要求。先配置用户会话空闲超时TMOUT在 /etc/profile.d/ 下创建一个脚本cat /etc/profile.d/tmout.sh EOF readonly TMOUT600 export TMOUT EOF这里用readonly的原因是防止用户在自己的shell里把超时变量改掉。TMOUT600 表示用户在终端里连续600秒10分钟没有任何操作会话就被自动退出。这个时间可以根据单位要求调整常见的有300秒和600秒。注意这个配置对已经登录的会话不会立即生效需要用户重新登录一次。如果你自己的SSH会话正好开着别原地等着它踢你重开一个窗口顺便测试下是否生效。接着配置SSH层面的空闲超时。编辑 /etc/ssh/sshd_configvi /etc/ssh/sshd_config找到或添加ClientAliveInterval 300 ClientAliveCountMax 0解释一下ClientAliveInterval 300服务器每300秒向客户端发送一个保活消息等待客户端响应。ClientAliveCountMax 0如果客户端连续0次即一次未响应立即断开连接。合起来的实际效果就是5分钟没有数据交互就断开。不要把ClientAliveCountMax设置得太大比如默认的3那样会拖到15分钟以上才断测评时测不出来。修改完成后重启SSH服务systemctl restart sshd重启SSH服务前一定要确认你当前会话不依赖于一个未保存的配置否则重启可能导致连接闪断。稳妥起见可以先用sshd -t检查配置语法sshd -t如果没有任何输出说明配置语法正确。再补充一个SSH层面的加固项。如果你们运维习惯用密码登录那就保持PasswordAuthentication yes靠上面的PAM策略做防护。如果单位已经强制用密钥登录可以顺手把密码登录关掉PasswordAuthentication no PermitRootLogin prohibit-password这样root远程只能用密钥登录密码策略性风险进一步降低。但这一步改之前必须确认所有管理员手上都有可用的私钥否则会把自己锁在门外。我见过不止一次因为关密码登录导致整个团队都进不去服务器的惨案。3.6 第六步批量处理存量用户很多系统上线时间久里面几十个账户的密码可能已经两年没动过了。等保测评时检查“定期更换”要求不会只看新建用户而是抽查所有可登录账户的chage信息。批量查看所有可登录用户的密码过期时间for user in $(awk -F: $7 ~ /(\/bin\/bash|\/bin\/sh)$/ {print $1} /etc/passwd); do echo $user chage -l $user | grep -E Password expires|密码过期 done如果发现有大量的“never”或早于90天的旧日期就要批量更新策略。执行下面的命令对所有可登录用户设置密码最长90天、最短7天、提前14天提醒for user in $(awk -F: $7 ~ /(\/bin\/bash|\/bin\/sh)$/ {print $1} /etc/passwd); do chage -M 90 -m 7 -W 14 $user done再啰嗦一句这个循环只处理shell为/bin/bash、/bin/sh等可登录账户的用户系统自带的服务账户nologin不去动它避免影响系统服务或守护进程的管理。有些等保同学会图省事直接对全量用户跑chage -M 90不要这么干系统账户强行设密码期限很可能给后面运维埋雷。批量设置完以后重新执行一遍查看命令确认每个账户都已经变成90天、7天、14天的状态这个步骤在测评整改报告里截图非常有用。还有一个顺手项检查是否存在空密码账户防止被当成严重漏洞awk -F: ($2){print $1} /etc/shadow如果这条命令有输出说明存在没有口令的账户必须立刻处理。正常情况下没有输出。4. 怎样证明策略已经生效自查与验证流程4.1 配置文件层面的自查配置完成后不要直接提交整改报告先自己检查一遍配置是否落到正确的位置。把下面这些命令跑一遍输出留档grep -E PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN|PASS_WARN_AGE /etc/login.defs grep -E minlen|dcredit|ucredit|lcredit|ocredit|minclass|maxrepeat /etc/security/pwquality.conf grep -E deny|unlock_time /etc/security/faillock.conf grep -E pam_pwquality|pam_pwhistory|pam_faillock /etc/pam.d/system-auth grep -E ClientAliveInterval|ClientAliveCountMax|PasswordAuthentication|PermitRootLogin /etc/ssh/sshd_config如果这些输出都是你预期中的值配置文件这关基本就稳了。4.2 实测验证密码复杂度光看配置还不够测评老师一定会动手测。我们要在自己可控的环境里先测一遍避免到现场翻车。找一个非root的普通测试用户比如testuser用root切换到该用户尝试修改密码passwd testuser然后输入一个弱密码比如“123456”或者“password”观察系统的反馈。正常情况下应该会提示密码不符合要求并被反复要求重新输入直到超过retry次数后报错。再试一个符合要求的强密码例如“Kylin2024Admin”这次应该能成功修改。如果强密码也报错大概率是密码长度或字符类别参数设置过于严格回头检查pwquality.conf里的取值适当放宽。这个“弱密码被拒、强密码通过”的测试过程我强烈建议用script命令记录会话输出留着当整改证据script -q /tmp/password-test.log passwd testuser exit测评老师看证据时你直接甩一份真实执行记录比空口说“我配置了”有力得多。4.3 实测验证登录失败锁定这一步同样要提前做并且要在非关键窗口执行避免触发告警或影响正在使用该服务器的同事。可以这样做比如故意连续输错testuser的密码5次su - testuser # 连续5次输入错误密码或者通过SSH尝试登录每次都输错密码ssh testuserlocalhost第5次失败后再尝试用正确密码登录系统应该提示账户已被锁定无法登录。此时可以用faillock命令查看锁定状态faillock --user testuser输出里会显示此次失败尝试的来源和失败次数。测试完后需要立即解锁因为测试用户可能还要继续用faillock --user testuser --reset再强调一遍这个测试最好别拿root账户做尤其在开启even_deny_root的情况下否则锁完自己都没法进入系统。4.4 测评前的一页纸自检清单根据我多次配合测评的经验整理一份自查清单如下建议打成表格贴在运维文档里检查项期望结果命令密码最长有效期90天chage -l testuser密码最短修改周期7天chage -l testuser密码过期提醒14天chage -l testuser密码长度至少12位grep minlen /etc/security/pwquality.conf包含字符类别四类各至少1个grep dcredit /etc/security/pwquality.conf连续相同字符限制不超过3个grep maxrepeat /etc/security/pwquality.conf登录失败锁定5次锁定30分钟grep deny /etc/security/faillock.conf密码历史记录最近5次不可重复grep pam_pwhistory /etc/pam.d/system-authSSH空闲超时5分钟断开grep ClientAliveInterval /etc/ssh/sshd_config会话空闲超时10分钟退出cat /etc/profile.d/tmout.sh空密码账户无输出awk -F: ($2){print $1} /etc/shadow测评现场老师基本上就按这些点抽查你提前把输出结果准备在当前目录下有的老师会让你现场执行看一遍所以命令要熟练别到现场翻笔记。5. 常见问题与避坑经验实录5.1 配置都改了弱密码还是能设置这个我遇到过很多次先别怀疑自己配置错了按下面顺序排查第一确认是否同时修改了system-auth和password-auth两个PAM文件。SSH的密码认证走的是password-auth本地登录走的是system-auth你只改其中一个就会出现“本地改不了弱密码SSH却能改”的情况测评老师往往就是用SSH登录后测试的当场翻车。第二检查pam_pwquality模块是否真的被调用。有的系统里system-auth里这行被注释了或者放在了错误的位置。用pam_listfile或者直接cat /etc/pam.d/system-auth检查。第三如果你用的是图形化界面里的“设置-用户”去改密码有些桌面环境不一定走完整的PAM密码复杂度检查。所以验证时尽量用passwd命令这才是测评老师最常用的路径。图形界面能不能拦住弱密码要不要拦截得看你们单位自己的要求。第四如果系统启用了authselect管理你手工改的PAM文件可能在authselect执行后被覆盖这种情况下要考虑用authselect的自定义profile或者在独立配置文件中落地。区分方法就是之前说的authselect current。5.2 登录失败锁定模块配错可能导致谁都登不进去这是我刚学PAM配置时踩过最痛的坑。当时我在system-auth里同时保留了pam_tally2和pam_faillock两套配置结果在某次测试时所有人都登录不进去了因为两个模块都在记录和判定失败次数把计数逻辑彻底搞乱了。新版麒麟系统默认用的是pam_faillock老的教程里常见的是pam_tally2。两个模块不能同时启用二选一并且要保证PAM堆栈里同一模块相关的preauth、authfail、authsucc顺序正确。如果不小心把自己锁外面了并且系统里设置了even_deny_root就非常被动了。唯一的办法是通过物理控制台、管理口、单用户模式或者重启进入紧急模式去清理锁定文件。faillock的计数文件在 /var/run/faillock/ 目录下root用户如果有权限可以手动删除对应文件rm -f /var/run/faillock/username所以再次强调改PAM文件前备份测试时换一个非关键用户始终保持一个当前root会话不要关掉。5.3 root账户到底要不要参与失败锁定这个问题我在不同单位遇到过截然不同的要求。有的测评老师说root也是账户必须锁定有的安全管理员说root一锁风险太大hold不住。我的建议是如果你们有带外管理口、物理控制台或者KVMroot可以参与锁定也就是启用even_deny_root这样测评最严格的要求也满足。如果你们只有SSH远程这一条路强烈建议不要启用even_deny_root否则一次误操作就把自己关在门外到时候恢复的成本远超等保整改带来的收益。折中方案是把SSH的PermitRootLogin设为prohibit-password关闭root的密码远程登录然后启用even_deny_rootroot即便在本地被锁也能通过管理员的普通账户sudo进入影响可控。5.4 密码历史记录不生效配置了pam_pwhistory但修改密码时还是能重复使用旧密码排查顺序如下先看 /etc/security/opasswd 这个文件是否存在。如果目录存在但文件不存在第一次修改密码时应该会自动创建。如果完全没有这个文件说明模块根本没被调用。再检查pam_pwhistory那一行放在哪里。如果放在了pam_unix之后历史检查可能不会生效因为pam_unix已经先完成了密码更新。要确保pam_pwhistory在password段比较靠前的位置比如我前面给的结构里放在pam_pwquality和pam_unix之前。最后查看 /etc/pam.d/password-auth 是否也配置了如果只改了system-authSSH密码修改这条路径就不会生效。还有一个不起眼但很常见的坑有些系统在password段用的是pam_unix.so并带remember参数同时也手动加了pam_pwhistory两套机制同时存在可能造成历史密码被记录两次行为看着正常但方向不统一。建议只用其中一种首选pam_pwhistory更直观。5.5 SSH密钥登录和密码策略的关系这里要澄清一个容易被人误解的点密码策略只对“用密码认证”这个动作生效。如果某个用户配置了SSH密钥并且sshd开启了PubkeyAuthentication那这个用户通过密钥登录时是不需要输入密码的PAM的复杂度、锁定策略都不会拦截。等保测评老师通常不会因为你有密钥登录就判定密码策略不符合他们会看密码登录这个通道是否被正确加固。所以你可以保持密码和密钥共存但前提是密码本身体系要强。如果你想彻底减少暴力破解风险就直接禁用密码登录只保留密钥但这时候密码策略更多是用来防本地控制台登录和sudo等场景。如果决定关密码登录请确保所有管理员密钥可用并至少保留一个带外通道或者让一名运维在机房待命再执行systemctl restart sshd我知道这句话已经说了三遍但还是得说因为真的有人会在重启后崩溃。5.6 修改 PAM 文件后是否需要重启服务PAM配置是动态读取的改完文件后新登录的连接立刻生效已经登录的会话不受影响。所以不需要重启sshd也不需要重启服务器。但SSH的配置文件修改后必须重启sshd才会生效。TMOUT配置需要新登录会话才生效。如果你在排查问题时发现改了PAM但系统好像还是老行为可以先看看有没有同时改到位再考虑是不是有缓存或其他模块在兜底比如有的系统会同时加载 /etc/pam.d/system-auth-ac注意同步。5.7 关于图形化工具与命令行的取舍麒麟系统自带的安全中心或类似图形工具理论上可以配置部分密码策略。但在等保整改场景下我更推荐命令行配置。原因很简单第一命令行的配置路径可重现一条命令能搞定的事情不用在图形界面点半天。 第二等保整改报告需要截图或脚本留痕命令行输出比图形界面截图更清晰也更好归档。 第三服务器版往往没装图形环境即使装了运维习惯也以命令行为主覆盖面更广。当然如果你们单位有统一的安全管控平台可以通过平台下发基线配置那就按平台的套路来命令行方案可以作为应急和复查手段并存。6. 最后再分享一点我的实际经验这套配置我在麒麟V10上前后调整过三轮最终形成了文章里的这套方案。整个过程让我最深刻的体会是等保整改不是把参数“配置上”就完了而是要保证每一项要求都有“活证据”也就是现场演示能通过、日志和截图能留痕。所以我的建议是每次改完配置都顺手把验证命令执行一遍把输出保存到整改报告里。比如弱密码被拒绝的终端输出、faillock的锁定记录、批量chage后的用户清单这些都是测评沟通时的硬通货。另外就是密码策略这东西过严会影响运维效率过松又过不了测评。建议先按文中的中等偏严级别配置遇到特殊账户和业务场景再单独豁免。所谓“特殊豁免”不是嘴上说说要在整改说明里写清楚原因比如某些自动化程序使用的服务账户无法90天改密码那就用密钥认证替代或设置专用策略并留存审批记录别等着测评组来质疑。最后再送一个实用小技巧在做任何PAM相关变更前一定要确保当前SSH会话不被中断再开一个新窗口测试登录。如果新窗口能正常登录再去动下一个文件如果新窗口登录失败立刻用备份恢复不要慌更不要一根筋地在断了连接的情况下瞎猜。多留一条后路比任何技巧都重要。