/etc/passwd权限应为644（-rw-r--r--），/etc/shadow必须为600（-rw-------）且属主为root:root，启用SELinux时还需restorecon恢复上下文，禁止使用chmod 700或编辑器直接操作以防备份文件泄露。
检查 /etc/passwd 和 /etc/shadow 的当前权限
这两个文件的权限直接决定系统账户安全底线。默认情况下，/etc/passwd 必须可被所有用户读取（否则 ls、su 等基础命令会异常），而 /etc/shadow 必须严格限制——仅 root 可读写，其他用户连读都不行。
实操建议：
- 用
ls -l /etc/passwd /etc/shadow一眼确认权限位，重点关注后九位（如-rw-r--r--或-rw-------） -
/etc/passwd合理权限是644（即-rw-r--r--），/etc/shadow必须是600（即-rw-------） - 如果看到
/etc/shadow权限是644或更宽松，立刻处理——这不是“可能有风险”，而是密码哈希已暴露
修复 /etc/shadow 权限错误的正确操作
不能只靠 chmod 600 /etc/shadow 就完事。很多管理员忽略 owner 和 group 是否匹配，导致即使权限数字对了，实际仍不可读或触发 SELinux 拒绝。
实操建议：
- 先确认 owner 是
root:root：ls -l /etc/shadow输出第一列和第二列必须都是root - 执行修复命令时带上 owner 重置：
sudo chown root:root /etc/shadow && sudo chmod 600 /etc/shadow - 在启用了 SELinux 的系统（如 RHEL/CentOS/Fedora）上，还需恢复上下文：
sudo restorecon /etc/shadow，否则login或sshd可能拒绝认证 - 切勿用
chmod 700—— 执行位对/etc/shadow完全无意义，反而可能干扰某些 PAM 模块判断
为什么改完权限后 su 或 ssh 登录突然失败？
常见现象不是“改不了权限”，而是“改完权限后服务崩了”。根本原因往往不是权限本身，而是修改过程中破坏了文件的 inode 属性或触发了安全模块拦截。
实操建议：
- 不要用文本编辑器直接打开
/etc/shadow—— 即使只是“看一眼”，某些编辑器（如nano）会偷偷创建备份文件（如/etc/shadow~），而该备份常被赋予错误权限，PAM 有时会误读它 - 检查是否存在残留备份：
ls -la /etc/shadow*，发现.swp、~、.bak文件一律删掉 - 验证
pam_pwquality.so或pam_faillock.so是否因文件属性异常被静默拒绝：查journalctl -u sshd | grep -i "auth"或tail -n 20 /var/log/secure - 临时测试是否权限问题：用
sudo -u nobody cat /etc/shadow 2>/dev/null || echo "blocked"，若输出blocked说明限制生效；若报错或输出内容，说明权限没设对
自动化检查脚本里容易漏掉的关键点
写一个定时检查 /etc/passwd 和 /etc/shadow 权限的脚本不难，但生产环境里真正出问题的，往往是脚本自己越权或判断逻辑太粗糙。
实操建议：
- 别用
stat -c "%a" /etc/shadow判断权限——它返回的是八进制数字，但有些系统（如旧版 BusyBox）不支持-c，应改用ls -l | cut -c1-10提取权限字符串再比对 - 脚本运行身份必须是 root，否则
ls -l /etc/shadow看不到真实权限（非 root 用户执行时会显示??????????） - 检查结果不能只写日志，要触发明确动作：比如权限异常时自动退出并返回非零码，让监控系统（如 Zabbix、Prometheus Alertmanager）能捕获
- 别把
/etc/passwd的检查逻辑和/etc/shadow写成同一段 if 判断——它们的安全等级完全不同，误判代价也不同
ls -lZ 和 journalctl -t su，比反复 chmod 有用得多。 
