最可靠方法是用chage命令设置单个用户密码过期时间，/etc/login.defs仅影响新建用户，已有用户必须单独执行chage -m 90等命令处理，二者需配合使用否则策略失效。
直接结论：用 chage 命令配单个用户最准，/etc/login.defs 只管新用户，两者必须配合，否则老用户永远不生效。
chage -M 设置密码最长有效期（最常用）
这是管理员日常操作频率最高的动作。比如要求用户每 90 天必须换一次密码：
sudo chage -M 90 username
注意：-M 参数只控制“密码本身过期”，不是账户失效；过期后用户仍可登录，但会被强制改密。常见错误是误以为设了 -M 就锁死了账户——其实没锁，得配合 -I 或 -E 才能真正禁用登录。
-
-M 0表示密码立即过期，用户下次登录就必须改密（等效于chage -d 0 username） -
-M -1或-M 99999表示密码永不过期（慎用，不符合等保或内部安全策略） - 普通用户执行会报错
Permission denied，必须用sudo或 root 权限
chage -W 和 -I 配合使用防漏登
只设 -M 不够，用户可能忽略警告、拖到过期当天才想起来。加 -W 提前通知，再用 -I 控制宽限期：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
sudo chage -W 7 -I 14 username
这表示：密码到期前 7 天开始提示；过期后还能再登录 14 天，但每次登录都必须改密；第 15 天起账户被锁定，无法登录。
-
-I值设为 0 意味着“密码一过期就立刻锁账户”，用户来不及响应，易引发运维求助 -
-I和-E是两回事：-E锁的是整个账户（连登录都不让），-I锁的是密码有效性（允许登录但必须改密） - 如果同时设了
-I 14和-E "2026-12-31"，以先触发者为准——比如密码在 12 月 1 日过期，-I给 14 天宽限，但账户在 12 月 10 日就因-E到期而彻底禁用
/etc/login.defs 只影响新用户，已有用户完全不受控
很多人编辑完 /etc/login.defs 里的 PASS_MAX_DAYS 90 就以为万事大吉，结果发现已有用户密码还是永远不提醒。这是因为该文件仅对 useradd 创建的新用户生效。
-
PASS_MAX_DAYS、PASS_MIN_DAYS、PASS_WARN_AGE这些参数只写进新用户的/etc/shadow初始值，不会反向覆盖已有用户 - 已有用户必须逐个跑
chage，或者用脚本批量处理，例如：for u in alice bob carol; do sudo chage -M 90 -W 7 "$u"; done
- 别用
date +%Y-%m-%d拼字符串传给-E——chage不认带空格或时区的格式，必须是严格YYYY-MM-DD
密码过期后还能登录？查 /etc/shadow 第三字段和 PAM auth 流程
用户密码过期后仍能登录，通常不是 chage 失效，而是 /etc/shadow 中该用户记录的第三字段（上次修改日期）和第九字段（账户过期日）没对齐，或 PAM 认证流程被绕过。
- 检查
chage -l username输出中Password expires和Account expires是否一致；不一致说明策略逻辑脱节 - SSH 密钥登录、
su -切换、cron 任务等场景完全绕过chage -d 0的强制改密机制 - 测试前务必用
ssh -o PubkeyAuthentication=no username@localhost模拟纯密码登录 - 若系统启用了 LDAP/SSSD，本地
chage几乎无效，得改服务端策略
真正麻烦的地方不在命令怎么敲，而在字段含义、PAM 层级覆盖、认证方式绕过这三层叠加影响——任何一个环节没对齐，策略就形同虚设。
