chage 命令失效主因是用户未启用 shadow 密码机制；需先用 passwd 初始化 /etc/shadow，确认文件存在且权限正确，并排除 nologin shell 影响；-E 设账号禁用日，-I 设密码过期后宽限期，后者须配合 -M 才生效。
chage 命令改不了密码过期时间？先检查用户是否被 shadow 锁定
执行 chage -M 90 username 没反应，或者查出来仍是 99999，大概率是该用户没启用 shadow 密码机制。老系统或手动添加的用户可能还在用 /etc/passwd 存密文，此时 chage 完全不生效。
- 运行
sudo grep username /etc/shadow，如果返回空，说明用户没进 shadow，得先用sudo passwd username设一次密码（触发 shadow 初始化） -
chage所有操作都依赖 /etc/shadow 文件，它不存在或权限不对（非 root 可读）也会静默失败 - 确认用户 shell 不是
/usr/sbin/nologin或/bin/false—— 这类账户即使密码过期策略设了，PAM 通常跳过校验
chage -E 和 -I 参数容易混淆：到期日 vs. 宽限期
-E 是账号**彻底禁用日期**（格式 YYYY-MM-DD），过了这天连 SSH 都登不进；-I 是密码过期后还能登录的**宽限期天数**，仅影响密码强制修改提示，但账户仍可用。
- 例如：
chage -E 2025-12-31 -I 7 username表示：2025-12-31 后账号锁死；若密码在之前就过期，用户还有 7 天窗口改密码，超时未改则无法登录（但账号没被-E删） -
-I必须配合-M（最大密码年龄）才有意义，单独设-I不会触发任何行为 - 宽限期期间，用户 ssh 登录会看到警告，但
su -或 cron 任务不受影响 —— 这点常被误认为策略失效
脚本批量设置 chage 策略时，别漏掉 --root 或 sudo 权限
在自动化部署或 Ansible 中调用 chage，常见错误是忘记权限或 chroot 上下文。
- 非 root 用户执行直接报错：
chage: Permission denied.—— 必须加sudo，且目标用户需在 sudoers 里允许该命令（或直接用 root 执行） - 容器或 chroot 环境中，
chage默认操作宿主机 /etc/shadow，要用--root /path/to/chroot指向正确根路径，否则策略写错地方 - 批量处理时用
while read u; do chage -M 60 "$u"; done ，注意 <code>"$u"加引号防用户名含空格出错
chage 查看结果里 “Password expires” 显示 “never” 怎么办
这不是 bug，而是 -M 被设为 99999（默认值），表示“永不过期”。很多管理员以为策略没生效，其实是没显式设置。
- 运行
chage -l username，看Maximum number of days between password change是否为99999 - 想真正启用过期，必须明确执行类似
chage -M 90 username，不能只设-W（警告天数）或-d（上次修改日） - 注意：
chage -d 0 username会让用户下次登录强制改密码，但不影响-M计算逻辑 —— 这个组合常被用来“重置密码周期”，但得配好-M才持续有效
真正麻烦的是时间计算逻辑：chage 把 -d（上次改密日）和 -M（最大天数）相加得出到期日，而 -d 默认是创建用户当天。如果用户长期没改过密码，实际到期日可能比你预期早得多 —— 这点在迁移老账户时最容易踩坑。
