上个月给客户的银河麒麟V10服务器做等保整改测评机构出的问题清单里身份鉴别这一块列了四条密码复杂度不达标、密码有效期没设、没有登录失败锁定、空闲会话不超时。不少运维听到这四个词第一反应是“这不就是改个login.defs的事”实际做完才发现真正的坑藏在系统认证机制里。这篇文章我把在KylinOS服务器上把密码强度策略完整落地的过程拆开讲包括等保检查项到底看什么、PAM认证链路怎么走、具体配置怎么改、怎么验证、以及最后怎么给测评师交一份说得过去的整改记录。正在做等保整改或者刚接手国产化服务器的同学可以直接照着操作。1. 等保密码项在查什么先给自己做一次“模拟测评”1.1 测评单上关于口令的检查点别指望测评师会一条条翻你的系统设置他们主要按安全计算环境中身份鉴别的要求来核对落到口令策略上核心就是下面这张表。检查项等保三级常见要求对应系统配置密码复杂度长度至少8位建议9位包含大写、小写、数字、特殊字符三类以上/etc/security/pwquality.conf密码有效期周期性更换常见90天最短使用期限常见1-7天/etc/login.defs、chage登录失败处理连续失败多次常见5次后锁定锁定时间建议600秒pam_faillock模块空闲会话超时无操作自动退出常见600秒内TMOUT环境变量、sshd_config不同测评机构的尺度会有差别有的要求密码必须四类字符全占有的允许三类但密码长度8位、90天更换、5次锁定这几条基本是共识。建议你按更严格的尺度去配省得测评报告回来还要二次整改。为什么很多老手会直接把长度设成9因为pwquality模块里的密码长度是“有效长度”dcredit、ucredit这几个参数会参与核算直接设8在很多组合下会被判不达标设9就稳了。后文我会在参数解释里展开讲。1.2 先做一次自检知道差在哪里动手之前先在服务器上把所有关键配置过一遍我一般用这几条命令cat /etc/security/pwquality.conf | grep -v ^# | grep -v ^$ grep -E ^PASS_ /etc/login.defs chage -l 某业务账号 grep -E pam_faillock|pam_pwquality|pam_tally2 /etc/pam.d/system-auth grep -r TMOUT /etc/profile /etc/profile.d/ 2/dev/null grep -E ClientAlive /etc/ssh/sshd_config每条输出对应一类检查项。pwquality.conf如果全是注释或者没有关键参数说明密码复杂度基本没生效login.defs里PASS_MAX_DAYS如果是99999说明密码永不过期pam.d里搜不到faillock相关行说明失败锁定没做TMOUT和ClientAlive都没输出说明空闲会话超时是空的。这一步能帮你快速列出整改清单也方便后面和测评师核对“改前改后”的差异。1.3 麒麟版本差异别忽略银河麒麟V10服务器版整体延续RHEL的体系PAM配置、用户管理、权限模型基本一致但不同SP版本之间还是有小差别。有的版本默认把pwquality.conf里的参数全部注释掉但PAM栈里已经加载了pam_pwquality模块有的版本默认没有加载faillock需要自己加。先确认系统版本cat /etc/kylin-release uname -m我见过有人在SP1上改的配置目录换到SP2后发现路径不对排查半天。操作前先确认版本后面每一步都看着实际文件做不要拿网上别人的整套配置直接覆盖。2. 修改密码策略前先把麒麟的认证链路走一遍2.1 一次SSH密码登录的完整链条很多人在这个问题上吃亏是因为把“改配置”理解成了“改文件内容”忽略了Linux认证不是某个程序自己拍板而是一串模块按顺序检查。打个比方把PAM认证链想象成机场安检pam_env是查证件pam_unix核对你是不是本人pam_faillock在旁边记你排了几次队、是不是可疑人物pam_pwquality负责检查你新设的密码本身够不够结实。这几个模块在/etc/pam.d/目录下按文件里的先后顺序执行任何一个环节说“不”后续就不用走了。对密码强度策略来说pam_pwquality模块在用户改密码时生效它读取/etc/security/pwquality.conf里的规则对用户新输入的密码做质量检查。pam_faillock则在用户认证时生效在认证提交前先查锁定状态认证失败后再记一笔。理解这个顺序你才能明白为什么有些配置“改了没反应”。2.2 为什么只改pwquality.conf可能不生效pwquality.conf只是一个规则库真正让它起作用的是PAM栈里必须有一行调用pam_pwquality.so。麒麟V10默认大部分情况是有的但也有精简安装的服务器或者之前被运维调整过PAM配置把这行删了。检查方法grep -E pam_pwquality|pam_pwcheck /etc/pam.d/system-auth /etc/pam.d/password-auth正常输出类似这样password requisite pam_pwquality.so try_first_pass local_users_only retry3如果什么都搜不到那你把pwquality.conf改成什么样都不会生效。需要在password段补一行password requisite pam_pwquality.so try_first_pass local_users_only retry3注意是password段不是auth段因为设置密码时走的通道是password管理组。很多人只盯着auth段看半天找不到问题所在就是这个原因。2.3 authselect机制可能带来的“改了被覆盖”还有一个容易被忽略的问题现在不少麒麟版本引入了authselect来统一管理认证配置。如果系统启用了authselect你手工改/etc/pam.d/system-auth可能在下次执行authselect命令时被覆盖回profile定义。可以先看当前状态authselect current如果系统提示使用的是某个profile建议通过authselect的custom配置去改或者确认后续运维流程不会有人执行authselect重新生成配置再考虑手工修改。这个点小但真遇到“改完第二天又恢复了”的情况时能少走很多弯路。3. 密码复杂度与有效期实操配置文件一步步改3.1 操作前先备份给自己留后路开始动文件之前先把要改的几个文件做一次备份。这个习惯救过我很多次尤其是PAM文件改错了轻则密码策略不生效重则所有用户都登不进去。mkdir -p /root/backup_$(date %Y%m%d) cp -a /etc/security/pwquality.conf /root/backup_$(date %Y%m%d)/ cp -a /etc/login.defs /root/backup_$(date %Y%m%d)/ cp -a /etc/pam.d/system-auth /root/backup_$(date %Y%m%d)/ cp -a /etc/pam.d/password-auth /root/backup_$(date %Y%m%d)/用cp -a保留文件权限和属性PAM配置文件如果权限不对可能导致认证模块读取异常。后面验证出问题直接把这个备份拷回去就行。我在帮客户整改时备份永远是第一步没有备份就不要动PAM。3.2 密码复杂度pwquality.conf推荐配置修改/etc/security/pwquality.conf去掉对应行的注释并调整参数。我给一套实测过、能满足等保三级要求的配置minlen 9 minclass 3 dcredit -1 ucredit -1 lcredit -1 ocredit -1 maxrepeat 3 usercheck 1 difok 5 retry 3逐条解释一下。minlen 9密码最小长度。前面我说过不建议只设8。在libpwquality的计算逻辑里dcredit这类参数会影响有效长度核算设置9能确保最终生效长度至少达到等保要求的8位留出余量。minclass 3至少包含三类字符。等保要求常用的是“三种或以上字符类型”这一项正好对应。dcredit -1、ucredit -1、lcredit -1、ocredit -1这四项分别要求数字、大写字母、小写字母、特殊字符至少出现一次。负数意味着“至少要有”如果设成正数反而是“允许有几个”0表示不限制。maxrepeat 3不允许同一个字符连续出现3次及以上防止aaaa这类弱密码。usercheck 1禁止密码中包含用户名。difok 5新密码相对旧密码至少要有5个字符不同防止用户只在原密码上改一个数字凑数。retry 3用户设置密码时如果不符合规则最多允许重新输入3次超过则报错。修改完不需要重启服务PAM模块每次读取配置。但如果你的PAM栈里没调用pam_pwquality记得按上一章的方式补上。3.3 密码有效期login.defs与chage的关系密码有效期配置在/etc/login.defs里等保场景下建议改成这样PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 8 PASS_WARN_AGE 7PASS_MAX_DAYS是密码最长使用天数90对应等保常见的“每三个月更换一次”PASS_MIN_DAYS是最短使用天数设7天避免用户被要求改密码后立刻又改回原密码PASS_WARN_AGE是到期前提前几天提醒设7天用户登录时会看到“密码将在7天后过期”的提示。但这里有个大坑login.defs只影响新建用户对存量用户不生效。也就是说你改完这个文件系统里已经存在的用户密码还是按原来的有效期走。这也是测评时最容易被打回的地方配置看着都改了一抽查某个老账户chage -l一看还是永不过期。解决办法见下一节。3.4 存量用户批量整改先用chage逐个确认存量用户的当前状态chage -l username如果发现大多数老用户都不符合90天要求写个循环批量处理。注意只处理登录用户排除系统账号避免把systemd服务账户、nobody这类系统账号也加上密码期限造成服务异常。for u in $(awk -F: $31000 $365534 {print $1} /etc/passwd); do chage -M 90 -m 7 -W 7 $u echo 已设置: $u doneawk的过滤条件是按UID范围判断银河麒麟V10的普通用户一般从1000开始。如果你们环境里有的用户是手工指定UID小于1000的需要额外把这个范围补进去。处理完抽查几个账号chage -l 业务账号看到最大密码使用期限为90、最短使用期限为7、提前警告天数为7说明存量整改生效了。4. 登录失败锁定与空闲超时两项配套加固别落下4.1 用pam_faillock实现失败锁定登录失败锁定通常会要求“连续失败5次锁定锁定时长不少于若干分钟”。麒麟V10推荐用pam_faillock模块比老的pam_tally2更通用。修改/etc/pam.d/system-auth和/etc/pam.d/password-auth两个文件auth段建议调整成类似下面的结构auth required pam_env.so auth required pam_faillock.so preauth audit deny5 unlock_time600 auth [success1 defaultbad] pam_unix.so try_first_pass auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time600 auth sufficient pam_faillock.so authsucc audit deny5 unlock_time600然后还要在account段加一行account required pam_faillock.so这里deny5是连续失败5次后锁定unlock_time600是锁定600秒10分钟audit是记录审计日志。preauth放在最前面作用是认证之前先检查用户是否已经被锁定authfail放在pam_unix之后作用是密码校验失败后记一次失败次数authsucc用于认证成功时清除失败计数。为什么这里要把pam_unix那一行改成[success1 defaultbad]的写法如果保留传统的auth sufficient pam_unix.so密码正确时认证会直接通过、跳过后面的authsucc失败计数就得不到清理密码错误时虽然会走到authfail但整个链路不够标准后续维护容易出幺蛾子。我建议直接按RHEL系最常见的faillock模板来这也是麒麟V10兼容性最好的做法。需要特别提醒不同版本的麒麟原来的system-auth内容会略有差异你只需要把pam_unix那一行替换成[success1 defaultbad]的形式再在它前面和后面分别插入faillock那几行不要拿网上的完整文件覆盖。改之前先diff一下当前文件和模板确认每一行的去向。4.2 会话空闲超时TMOUT与sshd双重控制等保里还会查空闲会话超时常见要求是10分钟无操作自动退出。这里有两个层面要配。第一个是shell层面在/etc/profile.d/下新建一个文件cat /etc/profile.d/timeout.sh EOF export TMOUT600 readonly TMOUT EOFTMOUT是bash的自动注销时间单位秒600就是10分钟。加readonly防止用户在自己环境里把它改掉。这里需要重新登录或者source一下才会对当前会话生效新登录的会话会直接加载。第二个是sshd层面修改/etc/ssh/sshd_configClientAliveInterval 300 ClientAliveCountMax 2ClientAliveInterval是服务器每隔300秒主动探测一次客户端ClientAliveCountMax是连续2次探测无响应就断开连接。这两个参数加起来基本能保证即使客户端异常断网服务器也不会一直吊着一个无用会话。改完用sshd -t检查语法确认没问题再重启sshd -t systemctl restart sshdTMOUT的主场是交互式shellsshd的探测对SSH连接是兜底。两个都配测评师无论看哪层都有话说。4.3 锁定效果怎么验证配置完faillock可以用一个测试账号从另一台机器模拟连续输错密码for i in $(seq 1 5); do ssh testuser服务器IP echo test 21 done连续输错5次后再输入正确密码会发现即使密码是对的SSH依然返回Permission denied因为preauth阶段直接拦住了。查看锁定状态faillock --user testuser登录失败N次一行行列在那里。等600秒后再试或者管理员手动解锁faillock --user testuser --reset这里要提醒别拿生产管理员账号去测连续5次错误真把管理员账户锁了如果又没配带外管理只能去物理控制台处理纯给自己找麻烦。5. 验证策略是否生效从弱密码测试到常见踩坑5.1 用最土的测试验证密码复杂度配置完成后创建一个临时测试用户直接尝试设置弱密码useradd pwtest echo 123456 | passwd --stdin pwtest如果pwquality生效系统会返回类似“BAD PASSWORD: The password fails the dictionary check”的错误并拒绝设置。再试试符合要求的密码比如Kylin2024Test这次能成功。测完把临时用户删掉userdel -r pwtest这个测试比任何工具都直观也能作为整改记录的一部分截图存档。注意用passwd --stdin需要确认你的系统支持银河麒麟V10一般可以如果不支持就直接用交互式passwd命令手动输入测试密码。5.2 PAM配置顺序错误的典型故障pam_faillock配置里最常见的问题是有人把preauth放到了pam_unix后面或者忘了在account段加那行。错误示例auth sufficient pam_unix.so try_first_pass auth required pam_faillock.so preauth audit deny5 unlock_time600这种情况下系统会先验证密码密码对就直接放行preauth不会被正确检查锁定状态配置形同虚设。另一个极端是有人把authfail直接放在preauth前面auth required pam_faillock.so authfail audit deny5 unlock_time600 auth required pam_faillock.so preauth audit deny5 unlock_time600这样每次登录都会先去记一次失败用户输一次正确密码也会被判定失败很快锁死所有账号。总结就是preauth必须最早authfail必须在pam_unix失败后authsucc最后收尾。手改PAM文件前先把当前system-auth备份好改完用另一个终端窗口试一次登录比什么都稳。5.3 改完SSH连不上怎么办如果配置完发现SSH连不上了先不要慌按这个顺序排查。确认你当前这个连接还活着。如果活着赶紧先检查sshd_config语法sshd -t。查看system-auth里有没有明显语法错误比如多写了不存在的模块名。直接对比备份文件diff /etc/pam.d/system-auth /root/backup_$(date %Y%m%d)/system-auth。只要当前会话没断把备份拷回去再重启sshd基本都能救回来。所以我反复强调远程改这类文件一定要保留当前会话另外开一个窗口测试新连接不要在一个会话里改完重启、然后等着看新连接能不能进来这等于把自己锁在门外。5.4 密码过期、忘记密码这些运维场景怎么处理等保整改过程中还有一类场景给老用户设了90天密码期限结果某个长期不登录的同事忘了密码或者root密码在改策略之后需要重置。麒麟V10上标准的应急处理是进入单用户模式或救援模式在维护环境下重新设置密码。这一步应当由有权限的运维人员在变更窗口内执行并通过操作记录、审计日志留痕而不是把它当成绕过安全机制的手段。日常运维更建议的做法是保留带外控制台或者现场控制台访问能力root密码复杂度也按统一标准设置并妥善保管。另外提醒一句如果用户密码已经过期SSH登录时会被强制要求先修改密码改完才能进入shell。这是Linux的正常行为不是故障整改后第一次密码批量到期时一定会有同事来问“为什么我登不上服务器”提前在群里打招呼能少接很多电话。5.5 让日志替你说话验证完之后去/var/log/secure里捞几条记录这是给测评师最直接的证据。查看失败的密码认证和失败锁定记录grep -i failed password /var/log/secure | tail -20 grep -i pam_faillock /var/log/secure | tail -20正常情况可以看到连续失败的IP、用户名和次数以及faillock模块的审计记录。这些日志配合配置截图比空口说“我已经配置好了”有力得多。6. 整改记录怎么做测评才不容易回来找茬6.1 给测评师的整改材料清单等保测评的最后提交材料如果只是把配置改完就结束测评师大概率还会要你的“整改证据”。我每次整改都会整理一份目录关键配置文件清单及关键参数截图pwquality.conf、login.defs、system-auth、sshd_config。用户密码有效期核对表对所有存量用户执行chage -l导出清单确认有效期均已收敛到90天以内。失败锁定测试记录弱密码和连续错5次锁定的实测过程截图。审计日志片段从/var/log/secure中提取的失败记录和faillock记录。变更信息操作人、操作时间、变更内容、影响范围、回退预案。这些不需要做得多花哨一张表格配上截图就行重点是让测评师能在现场快速复现“配置已生效”这一结论。6.2 把密码策略检查做成常态化整改是一次性的但等保要求是持续的。三个月后密码到期总会有用户把密码改成连续数字或者管理员图方便把某个账号的密码期限改回去。建议把检查做成脚本加入crontab定期扫一遍#!/bin/bash # 每日检查关键密码策略配置是否被改动 date /var/log/pwpolicy_audit.log awk -F: ($31000 $365534) {print $1, $2} /etc/shadow | while read user rest; do days$(chage -l $user | awk -F: /Maximum number of days/{print $2} | tr -d ) if [ $days -gt 90 ]; then echo WARN: $user 密码有效期超过90天 /var/log/pwpolicy_audit.log fi done这个脚本只是抛砖引玉实际项目里可以用Ansible或者更专业的配置管理工具统一下发。关键是让检查自动化而不是等下次测评前再熬夜补。6.3 与密码策略相关的其他延伸加固密码强度策略是等保身份鉴别控制点的一部分但测评还会看其他维度比如SSH是否允许root直接密码登录、是否启用了审计、不活跃账号是否禁用。如果时间允许建议顺手把SSH改为仅密钥登录、禁止root密码登录、给闲置90天以上的账号做禁用处理。这些和密码策略属于同一批检查项一起处理完整改效率会高很多。我在实际帮客户做整改时最大的体会是密码策略这类问题难点从来不是某个文件不会改而是你不知道自己不知道的坑。login.defs管不到存量用户PAM顺序错了会把自己锁外面TMOUT对SSH会话不一定兜底每个坑背后都是一段加班排障的回忆。每次改完配置留一份备份、留一个测试账号、留一个能进系统的后路这套流程跑顺了后面再遇到新服务器就能很快上手。 麒麟V10等保整改：从PAM认证到密码策略的完整落地指南
上个月给客户的银河麒麟V10服务器做等保整改测评机构出的问题清单里身份鉴别这一块列了四条密码复杂度不达标、密码有效期没设、没有登录失败锁定、空闲会话不超时。不少运维听到这四个词第一反应是“这不就是改个login.defs的事”实际做完才发现真正的坑藏在系统认证机制里。这篇文章我把在KylinOS服务器上把密码强度策略完整落地的过程拆开讲包括等保检查项到底看什么、PAM认证链路怎么走、具体配置怎么改、怎么验证、以及最后怎么给测评师交一份说得过去的整改记录。正在做等保整改或者刚接手国产化服务器的同学可以直接照着操作。1. 等保密码项在查什么先给自己做一次“模拟测评”1.1 测评单上关于口令的检查点别指望测评师会一条条翻你的系统设置他们主要按安全计算环境中身份鉴别的要求来核对落到口令策略上核心就是下面这张表。检查项等保三级常见要求对应系统配置密码复杂度长度至少8位建议9位包含大写、小写、数字、特殊字符三类以上/etc/security/pwquality.conf密码有效期周期性更换常见90天最短使用期限常见1-7天/etc/login.defs、chage登录失败处理连续失败多次常见5次后锁定锁定时间建议600秒pam_faillock模块空闲会话超时无操作自动退出常见600秒内TMOUT环境变量、sshd_config不同测评机构的尺度会有差别有的要求密码必须四类字符全占有的允许三类但密码长度8位、90天更换、5次锁定这几条基本是共识。建议你按更严格的尺度去配省得测评报告回来还要二次整改。为什么很多老手会直接把长度设成9因为pwquality模块里的密码长度是“有效长度”dcredit、ucredit这几个参数会参与核算直接设8在很多组合下会被判不达标设9就稳了。后文我会在参数解释里展开讲。1.2 先做一次自检知道差在哪里动手之前先在服务器上把所有关键配置过一遍我一般用这几条命令cat /etc/security/pwquality.conf | grep -v ^# | grep -v ^$ grep -E ^PASS_ /etc/login.defs chage -l 某业务账号 grep -E pam_faillock|pam_pwquality|pam_tally2 /etc/pam.d/system-auth grep -r TMOUT /etc/profile /etc/profile.d/ 2/dev/null grep -E ClientAlive /etc/ssh/sshd_config每条输出对应一类检查项。pwquality.conf如果全是注释或者没有关键参数说明密码复杂度基本没生效login.defs里PASS_MAX_DAYS如果是99999说明密码永不过期pam.d里搜不到faillock相关行说明失败锁定没做TMOUT和ClientAlive都没输出说明空闲会话超时是空的。这一步能帮你快速列出整改清单也方便后面和测评师核对“改前改后”的差异。1.3 麒麟版本差异别忽略银河麒麟V10服务器版整体延续RHEL的体系PAM配置、用户管理、权限模型基本一致但不同SP版本之间还是有小差别。有的版本默认把pwquality.conf里的参数全部注释掉但PAM栈里已经加载了pam_pwquality模块有的版本默认没有加载faillock需要自己加。先确认系统版本cat /etc/kylin-release uname -m我见过有人在SP1上改的配置目录换到SP2后发现路径不对排查半天。操作前先确认版本后面每一步都看着实际文件做不要拿网上别人的整套配置直接覆盖。2. 修改密码策略前先把麒麟的认证链路走一遍2.1 一次SSH密码登录的完整链条很多人在这个问题上吃亏是因为把“改配置”理解成了“改文件内容”忽略了Linux认证不是某个程序自己拍板而是一串模块按顺序检查。打个比方把PAM认证链想象成机场安检pam_env是查证件pam_unix核对你是不是本人pam_faillock在旁边记你排了几次队、是不是可疑人物pam_pwquality负责检查你新设的密码本身够不够结实。这几个模块在/etc/pam.d/目录下按文件里的先后顺序执行任何一个环节说“不”后续就不用走了。对密码强度策略来说pam_pwquality模块在用户改密码时生效它读取/etc/security/pwquality.conf里的规则对用户新输入的密码做质量检查。pam_faillock则在用户认证时生效在认证提交前先查锁定状态认证失败后再记一笔。理解这个顺序你才能明白为什么有些配置“改了没反应”。2.2 为什么只改pwquality.conf可能不生效pwquality.conf只是一个规则库真正让它起作用的是PAM栈里必须有一行调用pam_pwquality.so。麒麟V10默认大部分情况是有的但也有精简安装的服务器或者之前被运维调整过PAM配置把这行删了。检查方法grep -E pam_pwquality|pam_pwcheck /etc/pam.d/system-auth /etc/pam.d/password-auth正常输出类似这样password requisite pam_pwquality.so try_first_pass local_users_only retry3如果什么都搜不到那你把pwquality.conf改成什么样都不会生效。需要在password段补一行password requisite pam_pwquality.so try_first_pass local_users_only retry3注意是password段不是auth段因为设置密码时走的通道是password管理组。很多人只盯着auth段看半天找不到问题所在就是这个原因。2.3 authselect机制可能带来的“改了被覆盖”还有一个容易被忽略的问题现在不少麒麟版本引入了authselect来统一管理认证配置。如果系统启用了authselect你手工改/etc/pam.d/system-auth可能在下次执行authselect命令时被覆盖回profile定义。可以先看当前状态authselect current如果系统提示使用的是某个profile建议通过authselect的custom配置去改或者确认后续运维流程不会有人执行authselect重新生成配置再考虑手工修改。这个点小但真遇到“改完第二天又恢复了”的情况时能少走很多弯路。3. 密码复杂度与有效期实操配置文件一步步改3.1 操作前先备份给自己留后路开始动文件之前先把要改的几个文件做一次备份。这个习惯救过我很多次尤其是PAM文件改错了轻则密码策略不生效重则所有用户都登不进去。mkdir -p /root/backup_$(date %Y%m%d) cp -a /etc/security/pwquality.conf /root/backup_$(date %Y%m%d)/ cp -a /etc/login.defs /root/backup_$(date %Y%m%d)/ cp -a /etc/pam.d/system-auth /root/backup_$(date %Y%m%d)/ cp -a /etc/pam.d/password-auth /root/backup_$(date %Y%m%d)/用cp -a保留文件权限和属性PAM配置文件如果权限不对可能导致认证模块读取异常。后面验证出问题直接把这个备份拷回去就行。我在帮客户整改时备份永远是第一步没有备份就不要动PAM。3.2 密码复杂度pwquality.conf推荐配置修改/etc/security/pwquality.conf去掉对应行的注释并调整参数。我给一套实测过、能满足等保三级要求的配置minlen 9 minclass 3 dcredit -1 ucredit -1 lcredit -1 ocredit -1 maxrepeat 3 usercheck 1 difok 5 retry 3逐条解释一下。minlen 9密码最小长度。前面我说过不建议只设8。在libpwquality的计算逻辑里dcredit这类参数会影响有效长度核算设置9能确保最终生效长度至少达到等保要求的8位留出余量。minclass 3至少包含三类字符。等保要求常用的是“三种或以上字符类型”这一项正好对应。dcredit -1、ucredit -1、lcredit -1、ocredit -1这四项分别要求数字、大写字母、小写字母、特殊字符至少出现一次。负数意味着“至少要有”如果设成正数反而是“允许有几个”0表示不限制。maxrepeat 3不允许同一个字符连续出现3次及以上防止aaaa这类弱密码。usercheck 1禁止密码中包含用户名。difok 5新密码相对旧密码至少要有5个字符不同防止用户只在原密码上改一个数字凑数。retry 3用户设置密码时如果不符合规则最多允许重新输入3次超过则报错。修改完不需要重启服务PAM模块每次读取配置。但如果你的PAM栈里没调用pam_pwquality记得按上一章的方式补上。3.3 密码有效期login.defs与chage的关系密码有效期配置在/etc/login.defs里等保场景下建议改成这样PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 8 PASS_WARN_AGE 7PASS_MAX_DAYS是密码最长使用天数90对应等保常见的“每三个月更换一次”PASS_MIN_DAYS是最短使用天数设7天避免用户被要求改密码后立刻又改回原密码PASS_WARN_AGE是到期前提前几天提醒设7天用户登录时会看到“密码将在7天后过期”的提示。但这里有个大坑login.defs只影响新建用户对存量用户不生效。也就是说你改完这个文件系统里已经存在的用户密码还是按原来的有效期走。这也是测评时最容易被打回的地方配置看着都改了一抽查某个老账户chage -l一看还是永不过期。解决办法见下一节。3.4 存量用户批量整改先用chage逐个确认存量用户的当前状态chage -l username如果发现大多数老用户都不符合90天要求写个循环批量处理。注意只处理登录用户排除系统账号避免把systemd服务账户、nobody这类系统账号也加上密码期限造成服务异常。for u in $(awk -F: $31000 $365534 {print $1} /etc/passwd); do chage -M 90 -m 7 -W 7 $u echo 已设置: $u doneawk的过滤条件是按UID范围判断银河麒麟V10的普通用户一般从1000开始。如果你们环境里有的用户是手工指定UID小于1000的需要额外把这个范围补进去。处理完抽查几个账号chage -l 业务账号看到最大密码使用期限为90、最短使用期限为7、提前警告天数为7说明存量整改生效了。4. 登录失败锁定与空闲超时两项配套加固别落下4.1 用pam_faillock实现失败锁定登录失败锁定通常会要求“连续失败5次锁定锁定时长不少于若干分钟”。麒麟V10推荐用pam_faillock模块比老的pam_tally2更通用。修改/etc/pam.d/system-auth和/etc/pam.d/password-auth两个文件auth段建议调整成类似下面的结构auth required pam_env.so auth required pam_faillock.so preauth audit deny5 unlock_time600 auth [success1 defaultbad] pam_unix.so try_first_pass auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time600 auth sufficient pam_faillock.so authsucc audit deny5 unlock_time600然后还要在account段加一行account required pam_faillock.so这里deny5是连续失败5次后锁定unlock_time600是锁定600秒10分钟audit是记录审计日志。preauth放在最前面作用是认证之前先检查用户是否已经被锁定authfail放在pam_unix之后作用是密码校验失败后记一次失败次数authsucc用于认证成功时清除失败计数。为什么这里要把pam_unix那一行改成[success1 defaultbad]的写法如果保留传统的auth sufficient pam_unix.so密码正确时认证会直接通过、跳过后面的authsucc失败计数就得不到清理密码错误时虽然会走到authfail但整个链路不够标准后续维护容易出幺蛾子。我建议直接按RHEL系最常见的faillock模板来这也是麒麟V10兼容性最好的做法。需要特别提醒不同版本的麒麟原来的system-auth内容会略有差异你只需要把pam_unix那一行替换成[success1 defaultbad]的形式再在它前面和后面分别插入faillock那几行不要拿网上的完整文件覆盖。改之前先diff一下当前文件和模板确认每一行的去向。4.2 会话空闲超时TMOUT与sshd双重控制等保里还会查空闲会话超时常见要求是10分钟无操作自动退出。这里有两个层面要配。第一个是shell层面在/etc/profile.d/下新建一个文件cat /etc/profile.d/timeout.sh EOF export TMOUT600 readonly TMOUT EOFTMOUT是bash的自动注销时间单位秒600就是10分钟。加readonly防止用户在自己环境里把它改掉。这里需要重新登录或者source一下才会对当前会话生效新登录的会话会直接加载。第二个是sshd层面修改/etc/ssh/sshd_configClientAliveInterval 300 ClientAliveCountMax 2ClientAliveInterval是服务器每隔300秒主动探测一次客户端ClientAliveCountMax是连续2次探测无响应就断开连接。这两个参数加起来基本能保证即使客户端异常断网服务器也不会一直吊着一个无用会话。改完用sshd -t检查语法确认没问题再重启sshd -t systemctl restart sshdTMOUT的主场是交互式shellsshd的探测对SSH连接是兜底。两个都配测评师无论看哪层都有话说。4.3 锁定效果怎么验证配置完faillock可以用一个测试账号从另一台机器模拟连续输错密码for i in $(seq 1 5); do ssh testuser服务器IP echo test 21 done连续输错5次后再输入正确密码会发现即使密码是对的SSH依然返回Permission denied因为preauth阶段直接拦住了。查看锁定状态faillock --user testuser登录失败N次一行行列在那里。等600秒后再试或者管理员手动解锁faillock --user testuser --reset这里要提醒别拿生产管理员账号去测连续5次错误真把管理员账户锁了如果又没配带外管理只能去物理控制台处理纯给自己找麻烦。5. 验证策略是否生效从弱密码测试到常见踩坑5.1 用最土的测试验证密码复杂度配置完成后创建一个临时测试用户直接尝试设置弱密码useradd pwtest echo 123456 | passwd --stdin pwtest如果pwquality生效系统会返回类似“BAD PASSWORD: The password fails the dictionary check”的错误并拒绝设置。再试试符合要求的密码比如Kylin2024Test这次能成功。测完把临时用户删掉userdel -r pwtest这个测试比任何工具都直观也能作为整改记录的一部分截图存档。注意用passwd --stdin需要确认你的系统支持银河麒麟V10一般可以如果不支持就直接用交互式passwd命令手动输入测试密码。5.2 PAM配置顺序错误的典型故障pam_faillock配置里最常见的问题是有人把preauth放到了pam_unix后面或者忘了在account段加那行。错误示例auth sufficient pam_unix.so try_first_pass auth required pam_faillock.so preauth audit deny5 unlock_time600这种情况下系统会先验证密码密码对就直接放行preauth不会被正确检查锁定状态配置形同虚设。另一个极端是有人把authfail直接放在preauth前面auth required pam_faillock.so authfail audit deny5 unlock_time600 auth required pam_faillock.so preauth audit deny5 unlock_time600这样每次登录都会先去记一次失败用户输一次正确密码也会被判定失败很快锁死所有账号。总结就是preauth必须最早authfail必须在pam_unix失败后authsucc最后收尾。手改PAM文件前先把当前system-auth备份好改完用另一个终端窗口试一次登录比什么都稳。5.3 改完SSH连不上怎么办如果配置完发现SSH连不上了先不要慌按这个顺序排查。确认你当前这个连接还活着。如果活着赶紧先检查sshd_config语法sshd -t。查看system-auth里有没有明显语法错误比如多写了不存在的模块名。直接对比备份文件diff /etc/pam.d/system-auth /root/backup_$(date %Y%m%d)/system-auth。只要当前会话没断把备份拷回去再重启sshd基本都能救回来。所以我反复强调远程改这类文件一定要保留当前会话另外开一个窗口测试新连接不要在一个会话里改完重启、然后等着看新连接能不能进来这等于把自己锁在门外。5.4 密码过期、忘记密码这些运维场景怎么处理等保整改过程中还有一类场景给老用户设了90天密码期限结果某个长期不登录的同事忘了密码或者root密码在改策略之后需要重置。麒麟V10上标准的应急处理是进入单用户模式或救援模式在维护环境下重新设置密码。这一步应当由有权限的运维人员在变更窗口内执行并通过操作记录、审计日志留痕而不是把它当成绕过安全机制的手段。日常运维更建议的做法是保留带外控制台或者现场控制台访问能力root密码复杂度也按统一标准设置并妥善保管。另外提醒一句如果用户密码已经过期SSH登录时会被强制要求先修改密码改完才能进入shell。这是Linux的正常行为不是故障整改后第一次密码批量到期时一定会有同事来问“为什么我登不上服务器”提前在群里打招呼能少接很多电话。5.5 让日志替你说话验证完之后去/var/log/secure里捞几条记录这是给测评师最直接的证据。查看失败的密码认证和失败锁定记录grep -i failed password /var/log/secure | tail -20 grep -i pam_faillock /var/log/secure | tail -20正常情况可以看到连续失败的IP、用户名和次数以及faillock模块的审计记录。这些日志配合配置截图比空口说“我已经配置好了”有力得多。6. 整改记录怎么做测评才不容易回来找茬6.1 给测评师的整改材料清单等保测评的最后提交材料如果只是把配置改完就结束测评师大概率还会要你的“整改证据”。我每次整改都会整理一份目录关键配置文件清单及关键参数截图pwquality.conf、login.defs、system-auth、sshd_config。用户密码有效期核对表对所有存量用户执行chage -l导出清单确认有效期均已收敛到90天以内。失败锁定测试记录弱密码和连续错5次锁定的实测过程截图。审计日志片段从/var/log/secure中提取的失败记录和faillock记录。变更信息操作人、操作时间、变更内容、影响范围、回退预案。这些不需要做得多花哨一张表格配上截图就行重点是让测评师能在现场快速复现“配置已生效”这一结论。6.2 把密码策略检查做成常态化整改是一次性的但等保要求是持续的。三个月后密码到期总会有用户把密码改成连续数字或者管理员图方便把某个账号的密码期限改回去。建议把检查做成脚本加入crontab定期扫一遍#!/bin/bash # 每日检查关键密码策略配置是否被改动 date /var/log/pwpolicy_audit.log awk -F: ($31000 $365534) {print $1, $2} /etc/shadow | while read user rest; do days$(chage -l $user | awk -F: /Maximum number of days/{print $2} | tr -d ) if [ $days -gt 90 ]; then echo WARN: $user 密码有效期超过90天 /var/log/pwpolicy_audit.log fi done这个脚本只是抛砖引玉实际项目里可以用Ansible或者更专业的配置管理工具统一下发。关键是让检查自动化而不是等下次测评前再熬夜补。6.3 与密码策略相关的其他延伸加固密码强度策略是等保身份鉴别控制点的一部分但测评还会看其他维度比如SSH是否允许root直接密码登录、是否启用了审计、不活跃账号是否禁用。如果时间允许建议顺手把SSH改为仅密钥登录、禁止root密码登录、给闲置90天以上的账号做禁用处理。这些和密码策略属于同一批检查项一起处理完整改效率会高很多。我在实际帮客户做整改时最大的体会是密码策略这类问题难点从来不是某个文件不会改而是你不知道自己不知道的坑。login.defs管不到存量用户PAM顺序错了会把自己锁外面TMOUT对SSH会话不一定兜底每个坑背后都是一段加班排障的回忆。每次改完配置留一份备份、留一个测试账号、留一个能进系统的后路这套流程跑顺了后面再遇到新服务器就能很快上手。