批量配置修改后必须校验四类高危项：密码策略、账户锁定、ssh登录控制、关键文件权限；用inspec实现声明式校验，结果驱动闭环动作，并适配发行版差异。
批量修改配置后，真正难的不是“改完”，而是“确认改对了、没漏、没回退”。自动化校验不是加个echo "done"就结束，而是构建可验证、可追溯、可闭环的检查链。
聚焦关键项，避免全量扫描
校验必须有优先级。以下四类配置变更最易出错、影响最大，应作为每次批量操作后的必检项：
-
密码策略生效性：用
pam_pwquality --test --string "Test123!"验证模块加载与基础规则；再检查/etc/pam.d/common-password（Debian）或/etc/pam.d/system-auth（RHEL）中是否含password requisite pam_pwquality.so且参数未被注释 -
账户锁定机制：执行
sudo pam_tally2 -u testuser确认工具可用；检查/etc/pam.d/sshd是否存在auth [default=die] pam_tally2.so deny=5 unlock_time=900 -
SSH登录控制：运行
sshd -T | grep -E "(permitrootlogin|passwordauthentication|protocol)"，输出应为permitrootlogin no、passwordauthentication no、protocol 2 -
关键文件权限与属主：对
/etc/shadow、/etc/passwd、/etc/ssh/sshd_config逐个检查，例如stat -c "%a %U:%G" /etc/shadow结果应为600 root:root
用 InSpec 实现声明式校验
比起写一堆if [ $(grep ... | wc -l) -eq 0 ]，用 InSpec 更清晰、可复用、易集成：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 编写一个
controls/auth_baseline.rb，定义每个检查点的人类可读描述和预期状态 - 例如验证
/etc/login.defs中密码有效期：
control "PASS_MAX_DAYS must be 90" do
impact 1.0
title "Enforce maximum password age"
desc "Ensure passwords expire after 90 days"
describe file("/etc/login.defs") do
its("content") { should match /PASS_MAX_DAYS\s+90/ }
end
end - 执行
inspec exec ./profile -t ssh://admin@192.168.1.100 --key-files ~/.ssh/id_rsa --sudo，自动连接并返回结构化结果（JSON/HTML），失败项高亮标注
校验结果必须驱动闭环动作
发现不合规项不能只报错，要能触发下一步动作：
- 脚本末尾自动汇总不通过项数量与列表，若>0则
exit 1，阻断CI/CD流水线继续部署 - 对高危项（如
/etc/shadow权限非600、PermitRootLogin yes）生成修复建议命令，例如：chmod 600 /etc/shadow && chown root:root /etc/shadow - 将本次校验结果存档为带时间戳的JSON文件（如
audit_20260609_1740.json），供审计回溯
绕不开的发行版适配细节
同一行校验逻辑，在不同系统上路径、工具、输出格式可能不同：
- 判断系统类型：
grep -q "ubuntu" /etc/os-release && DISTRO="deb" || DISTRO="rhel" - PAM配置路径：Debian系用
/etc/pam.d/common-password，RHEL系用/etc/pam.d/system-auth，校验脚本需先探测再读取 - 账户锁定工具：RHEL 8+默认用
pam_faillock替代pam_tally2，inspec资源pam_conf可统一抽象，但自定义脚本需分支处理 - 避免硬编码
systemctl restart sshd——Ubuntu 22.04后sshd服务名改为ssh，应先systemctl list-unit-files | grep -E "(ssh|sshd)"动态识别
