chage命令设置密码过期时间可能不生效，因受/etc/login.defs、PAM策略、LDAP/SSSD或SSH密钥登录等影响；需结合chage -l验证、检查shadow字段及PAM配置，并确保密码认证登录。
chage 命令设置密码过期时间不生效？检查用户是否被 shadow 组策略覆盖
Linux 密码有效期不是只靠 chage 就能完全控制的，尤其在企业环境或启用了 PAM 的系统上，/etc/login.defs 和 /etc/pam.d/common-password 可能强制覆盖单个用户的设置。
实操建议：
- 先用
chage -l username确认当前设置是否已写入 shadow 数据库（注意看Last password change、Password expires等字段） - 检查
/etc/login.defs中的PASS_MAX_DAYS、PASS_MIN_DAYS、PASS_WARN_AGE—— 如果它们设为非零值，新用户默认继承，且某些 PAM 配置会无视chage对已有用户的修改 - 若使用 LDAP 或 SSSD，本地
chage几乎无效，需改服务端策略
强制用户首次登录改密码：用 chage -d 0 但得配合 shell 登录流程
chage -d 0 username 确实会让用户下次登录时被要求改密，但它只对交互式 shell 登录有效，SSH 密钥登录、sudo 切换、cron 任务等场景完全绕过这个机制。
常见错误现象：
- 用户用 SSH 密钥登录后没被提示改密，以为设置失败
- 用户通过
su -切换而非直接登录，同样跳过强制流程
实操建议：
- 确保用户使用密码认证方式登录（检查
/etc/ssh/sshd_config中PasswordAuthentication yes，且未禁用ChallengeResponseAuthentication） - 避免在
/etc/pam.d/sshd或common-auth中配置了[success=ok default=ignore] pam_succeed_if.so user ingroup nopasswdlogin类规则 - 测试前用
ssh -o PubkeyAuthentication=no username@localhost模拟纯密码登录
批量设置多用户密码策略：别直接 for 循环 chage，优先考虑 login.defs + usermod
用 for u in user1 user2; do chage -M 90 -W 7 "$u"; done 能跑通，但容易漏掉新创建用户，且无法统一管控密码复杂度等衍生策略。
更稳的做法是分层控制：
- 全局策略写进
/etc/login.defs（如PASS_MAX_DAYS 90），它影响所有后续新建用户 - 对已有用户补设，用
usermod --expiredate "" username清除账户过期时间，再配chage，避免和账户禁用时间冲突 - 密码复杂度必须配 PAM：启用
pam_pwquality.so并在/etc/pam.d/common-password中确认有类似password requisite pam_pwquality.so retry=3 minlen=10 difok=3的行
密码过期后用户还能登录？查 /etc/shadow 第三字段和 PAM auth 流程
用户密码过期后仍能登录，通常不是 chage 失效，而是 shadow 文件中该用户记录的第三字段（密码过期日期）为 99999 或空，或者 PAM 的 auth [default=die] pam_faildelay.so delay=3000000 类延迟机制干扰了判断逻辑。
关键点：
-
/etc/shadow每行第 3 字段是“上次改密距 1970-01-01 天数”，第 5 字段才是“最大使用天数”；第 4 字段（最小间隔）若为 0，允许立刻重设，但不等于允许过期后登录 - 真正阻止过期后登录的是 PAM 的
auth [default=die] pam_unix.so或pam_faildelay是否启用remember和shadow模块 - 最简验证法：临时注释掉
/etc/pam.d/common-auth中所有pam_deny.so或pam_permit.so行，只留pam_unix.so，再测试
实际环境中，PAM 配置比 shadow 字段更常成为“密码过期却不限制登录”的根因。改完任何一项，务必用非 root 用户真实走一遍登录流程，别只信 chage -l 输出。
