新系统应使用 pam_pwquality.so，它是 pam_cracklib.so 的继任者，支持更细粒度控制（如 unicode、重复字符限制），默认启用 dictcheck 和 retry；旧系统升级后可能软链接但参数不兼容，需统一迁移配置并确保 pam 加载顺序正确。
密码强度校验该用 pam_pwquality.so 还是 pam_cracklib.so
新系统建议直接用 pam_pwquality.so，它是 pam_cracklib.so 的继任者，支持更细粒度控制（比如 Unicode 字符、重复字符限制），且默认启用 dictcheck 和 retry。旧系统若升级过 libpwquality，pam_cracklib.so 实际会软链接到 pam_pwquality.so，但配置项不完全兼容——比如 minclass 在 cracklib 里无效，必须换用 minclass（pwquality）或 minlen（cracklib）这类不同命名的参数。
常见错误现象：password requisite pam_cracklib.so minlen=12 difok=5 在某些发行版（如 RHEL 8+）下静默失效，因为模块已重定向但参数未更新。
- 检查真实加载模块：
grep -r "pam_.*lib" /etc/pam.d/ | grep -v "^#" | head -n3 - 确认实际版本：
rpm -q libpwquality（RHEL/CentOS）或dpkg -l libpwquality1（Debian/Ubuntu） - 统一用
pam_pwquality.so配置，避免混用；旧配置迁移时把minlen改成minlen（它俩同名但 pwquality 多了minclass、maxrepeat等）
/etc/security/pwquality.conf 里哪些配置项真起作用
这个文件只被 pam_pwquality.so 读取，pam_cracklib.so 完全忽略它。很多管理员改了 pwquality.conf 却没生效，是因为 PAM 配置里没加载该模块，或者加载顺序错了（必须放在 password [success=1 default=ignore] pam_unix.so 之前）。
关键生效项（按优先级排序）：
-
minlen = 14：最小长度，注意不是“至少 14 位”，而是“至少 14 个字符”；含空格也算 -
minclass = 4：要求至少包含 4 类字符（大写、小写、数字、符号），但需配合enforcing = 1才强制 -
maxrepeat = 3：禁止连续 4 个相同字符（如aaaa） -
dictcheck = 1：启用字典检查，默认用/usr/share/cracklib/pw_dict，路径不对会导致跳过检查 -
reject_username = 1：密码中不得包含用户名（大小写不敏感）
容易踩的坑：retry = 3 必须写在 PAM 行里（如 password [default=bad] pam_pwquality.so retry=3），不能只写在 pwquality.conf 中。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
审计现有账户密码是否满足新策略
Linux 不存储明文密码，无法直接比对是否符合 minclass=4 这类规则。只能间接验证：用 chage -l <username></username> 看密码修改时间，再结合日志和策略生效时间倒推；或用工具模拟校验——最可靠的是调用 libpwquality 的 API 或复用 PAM 流程。
实操建议：
- 临时启用 debug 模式快速验证：
password [debug] pam_pwquality.so try_first_pass local_users_only，然后用passwd改密，看/var/log/secure是否输出pwquality: check failed类信息 - 批量检查弱密码用户（需 root）：
awk -F: '($2 ~ /^\$/ && $2 !~ /^\$6\$/){print $1}' /etc/shadow，筛选出非 SHA-512 加密的账户（可能用的是弱哈希或空密码） - 合规审计重点不是“当前密码是否强”，而是“密码修改行为是否受控”——查
/var/log/secure中passwd调用记录 + 对应 PAM 模块返回值（success/failure）
SELinux 或 systemd-logind 干扰密码策略生效
在启用了 SELinux 的系统（如 RHEL/CentOS 默认）上，pam_pwquality.so 访问 /usr/share/cracklib/pw_dict 可能被拒绝，日志里出现 avc: denied { read } for ... comm="passwd" name="pw_dict"。这不是配置写错，而是上下文类型不匹配。
另一个常见干扰源是 systemd-logind：它接管了部分本地登录流程，绕过 /etc/pam.d/login，导致图形界面或 loginctl unlock-session 场景下密码策略不触发。
- 修复 SELinux 拒绝：运行
restorecon -v /usr/share/cracklib/pw_dict*，或临时用setsebool -P authlogin_nsswitch_use_ldap on（仅当确实需要 LDAP 集成时） - 确认所有入口都覆盖：检查
/etc/pam.d/system-auth（被 login、su、sudo 共用）和/etc/pam.d/password-auth（被 sshd、gdm 等引用），确保pam_pwquality.so出现在password段且位置靠前 - 测试非 SSH 场景：用
su - <username></username>和ssh localhost分别验证，避免只测一种路径就认为“已生效”
真正麻烦的是跨服务一致性——比如 sshd 用 password-auth，而 cron 启动的脚本根本不用 PAM，这种场景下“密码合规”只对交互式登录有效，审计时得明确标注适用范围。
