必须执行chage -d 0 username并确保PAM password规则启用，否则仅设状态无效；该操作将shadow中last password change置为0，触发登录时强制改密，但密钥登录和root账户常被豁免。
直接结论：用 chage -d 0 username，但仅此不够——必须确认 PAM 模块已启用密码过期拦截逻辑，否则用户照样进 shell。
chage -d 0 是核心动作，不是“设个时间”就完事
它把 /etc/shadow 中该用户的 “last password change” 字段设为 0（即 1970-01-01），系统据此判定“密码已过期”。但这只是状态标记，不自动触发改密流程。
- 执行后立刻生效，无需重启服务或重载配置
- 验证是否成功：
chage -l username中 “Password must be changed” 显示yes - 注意：
passwd -e username效果等价，但语义不如chage -d 0直观，且部分老发行版对passwd -e支持不稳定 - 该操作不影响当前已登录会话，只对新建立的认证连接生效
为什么用户 SSH 登录后没被拦住？大概率是 PAM 没配对
Linux 不靠 chage 自己弹窗，而是由 PAM 在认证通过后检查状态，并决定是否跳转到 passwd。如果 PAM 配置缺失或被跳过，chage -d 0 就形同虚设。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 检查
/etc/pam.d/sshd（SSH）或/etc/pam.d/common-password（通用）中是否存在类似这行：password [success=ok default=ignore] pam_pwquality.so retry=3或password requisite pam_unix.so sha512 shadow nullok - 关键点：必须有
password类型的规则，且不能被auth [default=ignore]等提前终止的规则覆盖 - Ubuntu 22.04+、RHEL 8+ 默认启用了
pam_pwquality，但若手动注释过相关行，或使用了精简镜像，可能实际未加载 - 别用
root测试——很多 PAM 规则对 root 账户豁免，新建普通用户 + 密码登录验证才可靠
密钥登录用户不会触发强制改密，这是设计使然
SSH 密钥认证绕过了密码校验环节，PAM 的密码过期检查根本不会运行。这不是 bug，是机制限制。
- 如果你依赖密钥登录，又需要强制改密，得额外处理：要么临时禁用密钥登录（改
/etc/ssh/sshd_config中PasswordAuthentication yes），要么在业务层做二次校验（比如登录后脚本检测chage -l $USER | grep "must be changed"并阻断） - 图形界面（GDM、SDDM）通常能正确响应
chage -d 0，因为它们走的是 PAM auth + account 流程，比纯 SSH 更完整 - LDAP 或 SSSD 环境下，
chage对本地/etc/shadow有效，但远程目录用户需另配pwdMaxAge等属性，chage -d 0对其无效
批量设置和常见误判点
批量操作容易漏掉系统账户或权限异常用户，而日志里往往只报模糊错误。
- 筛选普通用户再操作：
getent passwd | awk -F: '$3 >= 1000 {print $1}' | xargs -I{} sudo chage -d 0 {} - 查谁被设成了强制改密：
sudo awk -F: '$5 == "0" {print $1}' /etc/shadow（$5是 shadow 第五字段，即 last password change） - 如果用户登录时报
Authentication token manipulation error，先看/var/log/auth.log，大概率是 PAM 拒绝了新密码（比如强度不够、重复历史密码），不是chage没生效 - Web 应用或容器内应用若自己实现登录逻辑，完全不读
/etc/shadow，那chage设置对其零影响——这类场景必须在应用代码里加状态判断
真正卡住人的从来不是命令敲错，而是以为设了 chage -d 0 就万事大吉，结果忘了 PAM 这一层，或者压根没意识到密钥登录会绕过整个机制。
