配置Linux用户密码过期时间主要通过chage命令管理单个用户和修改/etc/login.defs设置新用户默认策略。使用chage -M、-W、-m等选项可设定密码最长有效期、警告天数和最短修改间隔，如sudo chage -M 90 -W 7 testuser使密码90天后过期并提前7天警告；通过编辑/etc/login.defs中的PASS_MAX_DAYS等参数可为新用户设定默认策略，例如PASS_MAX_DAYS 90。查看用户策略用chage -l username，输出包含密码修改、过期、警告等详细信息。批量修改现有用户需结合awk解析/etc/passwd筛选普通用户，并在循环中调用chage命令，如for user in $(awk -F: '$3>=1000 && $1!="nobody" {print $1}' /etc/passwd); do sudo chage -M 90 -W 7 "$user"; done。实际应用中需注意服务账户处理、避免频繁过期导致弱密码问题，推荐结合密码复杂度、历史限制和多因素认证（MFA）提升安全性，同时定期审计日志并进行安全意识培训，构建纵深防御体系。
在Linux系统中，配置用户密码的过期时间主要通过
chage命令以及修改
/etc/login.defs文件来实现。这两种方法各有侧重，
chage用于管理单个现有用户的密码策略，而
/etc/login.defs则设定了新创建用户的默认密码策略。这是一个核心的安全实践，旨在强制用户定期更新密码，从而降低因密码泄露或猜测而导致的安全风险。
解决方案
要具体配置Linux用户密码的过期时间，我们通常会用到以下几种方法：
首先，对于单个现有用户，
chage命令是你的首选工具。这个命令非常强大，可以精细控制用户的密码有效期、最短修改间隔、过期前警告天数以及账户本身的失效日期。
比如，你想让用户
testuser的密码在90天后过期，并且在过期前7天开始警告他：
sudo chage -M 90 -W 7 testuser
这里的
-M 90表示密码最长有效期是90天，
-W 7表示在密码过期前7天开始提醒用户。
如果你想设置用户密码至少在3天后才能再次修改（避免用户立即改回旧密码），可以这样做：
sudo chage -m 3 testuser
-m 3就是设置密码最短修改间隔为3天。
还有一种情况，如果用户密码已经过期，但你希望给他一个宽限期，比如10天，让他在这10天内登录并修改密码，否则账户将被锁定：
sudo chage -I 10 testuser
这里的
-I 10设置了密码过期后的非活动天数。
甚至，你可以直接设置一个账户的最终过期日期，到那天无论密码是否过期，账户都会失效：
sudo chage -E 2024-12-31 testuser
这在管理临时账户或者项目结束时非常有用。
其次，对于新创建的用户，我们希望他们一开始就遵循一定的密码策略，这时就需要修改
/etc/login.defs文件。这个文件定义了系统范围内用户和密码管理的默认参数。
打开
/etc/login.defs文件（通常需要root权限）：
sudo vi /etc/login.defs
你会看到类似这样的几行（可能被注释掉了）：
#PASS_MAX_DAYS 99999 #PASS_MIN_DAYS 0 #PASS_WARN_AGE 7
PASS_MAX_DAYS
：设置密码最长有效期，例如将其改为PASS_MAX_DAYS 90
，那么新创建的用户密码默认将在90天后过期。PASS_MIN_DAYS
：设置密码最短修改间隔，例如PASS_MIN_DAYS 3
，新用户密码修改后至少3天才能再次修改。PASS_WARN_AGE
：设置密码过期前多少天开始警告用户，例如PASS_WARN_AGE 7
。
需要注意的是，修改
/etc/login.defs文件只对之后创建的用户生效，对已经存在的用户没有任何影响。所以，如果你想对现有用户应用新的全局策略，你可能还需要结合
chage命令进行批量操作。
如何查看Linux用户密码的当前过期策略？
了解一个用户的密码策略是管理工作的基础。在Linux中，最直接、最准确的方式就是使用
chage命令，加上
-l（list）选项，后面跟上用户名。
例如，要查看用户
testuser的密码过期信息：
sudo chage -l testuser
输出会非常详细，通常包含以下几项：
一个经过完善设计的经典网上购物系统，适用于各种服务器环境的高效网上购物系统解决方案，shopxp购物系统Html版是我们首次推出的免费购物系统源码，完整可用。我们的系统是免费的不需要购买，该系统经过全面测试完整可用，如果碰到问题，先检查一下本地的配置或到官方网站提交问题求助。 网站管理地址：http://你的网址/admin/login.asp 用户名：admin 密 码：admin 提示：如果您
Last change : Jul 15, 2024 # 上次密码修改日期 Password expires : Oct 13, 2024 # 密码过期日期 Password inactive : never # 密码过期后账户非活动天数，never表示永不非活动 Account expires : never # 账户过期日期，never表示永不失效 Minimum number of days between password change : 0 # 两次密码修改之间的最短天数 Maximum number of days between password change : 90 # 两次密码修改之间的最长天数 Number of days of warning before password expires : 7 # 密码过期前警告天数
通过这些信息，你可以清晰地知道当前用户的密码状态和策略。如果
Password expires显示为
never，通常意味着该用户没有设置密码过期策略，或者其
PASS_MAX_DAYS被设置为一个非常大的值。
除了
chage -l，你也可以查看
/etc/login.defs文件来了解系统默认的密码策略。但请记住，这只是默认值，不代表所有现有用户的实际情况。现有用户的实际策略存储在
/etc/shadow文件中，
chage命令就是读取和修改这个文件来工作的，但我们通常不直接编辑
shadow文件，因为它包含了敏感的密码哈希信息，直接编辑容易出错且不安全。
如何为新用户设置默认密码过期策略，并批量修改现有用户？
为新用户设置默认密码策略，我们刚才提到了，主要就是通过编辑
/etc/login.defs文件。这是系统级别的配置，一旦修改并保存，之后通过
useradd命令创建的任何新用户都会继承这些设置。
例如，如果你想让所有新用户默认密码90天过期，最短修改间隔5天，过期前10天警告：
sudo vi /etc/login.defs
找到并修改（或取消注释）以下行：
PASS_MAX_DAYS 90 PASS_MIN_DAYS 5 PASS_WARN_AGE 10
保存并退出。之后创建的用户，比如
sudo useradd newuser，就会自动应用这些策略。
至于批量修改现有用户的密码过期策略，这在企业环境中非常常见，比如为了满足合规性要求，需要对所有普通用户强制执行新的密码过期规则。这时，我们可以结合
chage命令和Shell脚本的循环功能。
一个常见的场景是，我们想把所有普通用户的密码最长有效期都设置为90天。首先，我们需要获取所有普通用户的列表。通常，UID大于1000（或特定发行版如CentOS 500）且不是
nobody的用户被认为是普通用户。
你可以这样做：
for user in $(awk -F: '$3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd); do
echo "Processing user: $user"
sudo chage -M 90 -W 7 "$user"
# 如果还需要设置最短修改间隔，可以加上 -m
# sudo chage -m 3 "$user"
done这段脚本会遍历
/etc/passwd文件，筛选出UID大于等于1000且用户名不是
nobody的用户，然后对每个用户执行
chage -M 90 -W 7命令，将其密码最长有效期设置为90天，并在过期前7天发出警告。
重要提示： 在执行任何批量操作之前，务必先在一个测试环境或对少量用户进行测试。同时，要仔细考虑是否需要排除某些特殊的服务账户或系统账户，因为它们可能不适合遵循标准的密码过期策略（例如，某些自动化脚本使用的账户可能依赖于长期不变的密码或密钥认证）。错误的批量操作可能会导致大量用户无法登录，造成生产环境中断。
密码过期策略的常见挑战、最佳实践与安全性考量
密码过期策略听起来很美，但实际落地时，我们往往会遇到一些挑战，并且需要结合最佳实践和更广阔的安全性视角来考量。
常见挑战：
-
用户体验与弱密码问题： 最常见的抱怨就是“密码改得太频繁了，我记不住”。这导致用户可能采取一些不安全的行为，比如使用非常简单、容易猜测的密码（比如
password123
），或者更糟糕的是，将密码写在便利贴上、保存在未加密的文档中。讽刺的是，强制过期反而可能降低实际的密码强度。 - 管理复杂性： 频繁的密码过期会导致更多的用户忘记密码，从而增加IT支持团队的工作量。账户锁定也是一个常见问题，尤其是当用户尝试次数过多导致账户被锁定，需要管理员介入解锁。
- 服务账户与自动化脚本： 很多自动化任务、服务或应用程序会使用特定的用户账户来运行。这些账户的密码如果强制过期，可能会导致服务中断，因为它们通常不具备交互式登录来修改密码的能力。处理这类账户的密码过期是一个特殊的挑战。
最佳实践：
- 平衡过期频率与复杂度要求： 过于频繁的过期（比如30天）往往适得其反。一个更合理的周期可能是90到180天。更重要的是，应该结合强制性的密码复杂度要求（长度、大小写、数字、特殊字符）和历史密码限制（不允许使用最近N次用过的密码）。这样，即使密码不经常过期，其强度也能得到保证。
- 教育用户： 仅仅强制过期是不够的，还需要对用户进行安全意识培训，让他们理解为什么需要设置强密码、如何创建易记但难猜的密码，以及密码管理的重要性。
- 多因素认证 (MFA)： 这绝对是现代安全实践的基石。如果你的系统支持MFA，那么在很大程度上，MFA可以弥补单一密码的不足。在MFA的保护下，甚至可以适当放宽密码过期要求，因为即使密码被盗，攻击者也无法仅凭密码登录。
- 服务账户的特殊处理： 对于自动化脚本或服务账户，尽量避免使用需要定期修改的密码。优先考虑使用密钥对认证（SSH密钥）、API令牌、或者专业的秘密管理工具（如HashiCorp Vault、AWS Secrets Manager）来管理凭据。这些方法通常比定期修改密码更安全、更易于管理。
- 定期审计与日志监控： 无论密码策略如何，都应该定期审计用户账户活动和系统日志，以便及时发现异常行为，这比单纯依赖密码过期要有效得多。
安全性考量：
密码过期策略是“纵深防御”安全策略中的一环，但它绝不是银弹。一个完善的安全体系需要多方面协同工作：
- 强密码策略本身： 不仅是过期，还有长度、复杂度和历史限制。
- 多因素认证 (MFA)。
- 最小权限原则： 用户和应用程序只拥有完成任务所需的最小权限。
- 入侵检测与预防系统 (IDS/IPS)。
- 安全补丁管理： 及时更新系统和应用程序，修复已知漏洞。
- 安全意识培训。
- 日志审计与监控。
在我看来，盲目追求“密码过期越频繁越安全”的观念是片面的，甚至可能适得其反。我们应该更注重密码的整体强度和多因素认证的部署，将密码过期策略作为一个辅助手段，并根据实际业务需求和风险评估来制定，而不是一刀切地强制执行。毕竟，一个强壮但永不过期的密码，可能比一个频繁更换但每次都换成“password123”的密码要安全得多。
