要配置linux用户密码历史，需使用pam_pwhistory.so模块并编辑pam配置文件。1. 确定配置文件路径（如/etc/pam.d/system-auth或password-auth）；2. 在password堆栈中添加或修改pam_pwhistory.so行，设置remember参数以指定历史密码数量，并置于pam_unix.so之前；3. 保证/etc/security/opasswd文件权限正确，由系统自动管理；4. 修改后立即生效，无需重启服务。该策略提升账户安全性、满足合规要求、引导用户创建新密码。验证方法包括尝试重复使用旧密码及检查opasswd文件状态；排查问题应核对配置语法、查看系统日志、确认文件权限与selinux/apparmor状态。
配置Linux用户密码历史，核心在于利用PAM（Pluggable Authentication Modules）中的
pam_pwhistory.so模块，并确保
/etc/security/opasswd文件能够正确记录和比对旧密码哈希。这个文件是系统用来存储用户历史密码散列值的地方，防止用户重复使用近期用过的密码，是系统安全策略中不可或缺的一环。
解决方案
要配置Linux用户密码历史，主要是在PAM配置文件中进行操作，通常是
/etc/pam.d/system-auth或
/etc/pam.d/password-auth，具体取决于你的Linux发行版和PAM配置方式。
-
确定PAM配置文件： 大多数现代Linux系统（如CentOS/RHEL、Ubuntu等）会通过软链接将
system-auth
和password-auth
指向同一个文件，或者这两个文件独立存在。你可能需要修改其中一个或两个。通常，password-auth
更侧重于密码管理。
编辑PAM文件： 使用文本编辑器（如
vi
或nano
）打开选定的PAM配置文件，例如：sudo vi /etc/pam.d/system-auth
或sudo vi /etc/pam.d/password-auth
-
添加或修改
pam_pwhistory.so
行： 在password
堆栈中找到类似下面的行（如果存在）：password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
在这行之前，添加或修改pam_pwhistory.so
模块。一个典型的配置示例如下：
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password requisite pam_pwhistory.so remember=5 enforce_for_root
这里，
remember=5
表示系统会记住用户最近的5个密码，不允许重复使用。enforce_for_root
则意味着这个策略也对root用户生效。你可以根据需要调整remember
的值。注意：
pam_pwhistory.so
必须在pam_unix.so
（或处理实际密码更新的模块）之前，并且通常使用requisite
或required
控制标志，以确保如果历史密码检查失败，密码更改操作会立即终止。requisite
是更严格的选择，它不仅会终止操作，还会立即返回失败信息，而required
则会继续处理堆栈中的其他模块，但最终仍会返回失败。 /etc/security/opasswd
文件： 这个文件是pam_pwhistory.so
模块用来存储用户密码历史哈希值的地方。你不需要手动创建或修改它。当pam_pwhistory.so
模块被调用时，它会自动管理这个文件。确保该文件及其父目录的权限设置是安全的，通常只有root用户有读写权限。 例如，权限通常是600
，所有者是root:root
。
完成上述步骤后，保存文件。新的密码历史策略将立即生效，无需重启服务。
为什么需要强制执行Linux密码历史策略？
这其实是个老生常谈的话题了，但每次讨论到系统安全，它总能被拎出来，因为它确实有效。想象一下，如果一个用户可以无限次地循环使用“password123”或者他自己的生日作为密码，那这个账户的安全边界就脆弱得像纸糊的一样。强制执行密码历史策略，最直接的原因就是提升账户安全性，防止用户因为图省事而重复使用旧密码。
从更深层次看，这背后有几个考量：
首先是抵御字典攻击和暴力破解。当攻击者获取到用户密码的哈希值，他们会尝试各种常见的密码组合，甚至利用泄露的密码数据库进行反向查询。如果用户频繁重复使用旧密码，一旦其中一个旧密码泄露，或者攻击者通过某种方式推测出用户曾经用过的密码，那么即使他们更改了密码，也可能只是在已知的“旧密码池”里打转，攻击者可以轻易地再次得手。密码历史策略迫使用户创建新的、未曾使用过的密码，增加了攻击者猜测或破解的难度。
其次是满足合规性要求。很多行业标准和法规，比如PCI DSS（支付卡行业数据安全标准）、HIPAA（健康保险流通与责任法案）以及GDPR（通用数据保护条例）等，都对密码策略有明确的规定，包括密码复杂性、有效期以及历史密码的禁用。遵循这些规定，不仅是为了避免罚款，更是为了构建一个负责任、可信赖的信息安全环境。如果你在一个需要高度合规的环境中工作，这个配置几乎是标配。
再者，这是一种用户行为引导。虽然有些用户可能会觉得麻烦，但从系统管理的角度看，这是在潜移默化地培养用户良好的安全习惯。当他们知道不能重复使用密码时，自然会倾向于创建更独特、更难预测的新密码，而不是仅仅在旧密码上做微小改动。这是一个系统管理员对用户安全意识的“软干预”。
最后，虽然
/etc/security/opasswd这个文件本身看起来不起眼，它只是一个存储哈希值的地方，但它的存在让
pam_pwhistory.so有了“记忆”。没有它，或者它被破坏，模块就无法知道用户以前用过什么密码，密码历史策略也就形同虚设了。所以，这个文件是整个策略能够生效的基石。
pam_pwhistory.so模块在密码策略中扮演什么角色？
pam_pwhistory.so模块在Linux的密码策略中扮演着一个至关重要的“记忆守护者”角色。理解它的作用，首先要对PAM（Pluggable Authentication Modules，可插拔认证模块）有一个基本概念。PAM是一个灵活的框架，它将应用程序（如
login、
passwd、
ssh等）的认证、账户管理、会话管理和密码管理功能与实际的认证机制分离。这意味着系统管理员可以根据需要，插入或拔出不同的模块来定义认证行为，而无需修改应用程序本身。
pam_pwhistory.so就是PAM框架下专门用于处理“密码历史”的模块。它的核心功能是：
-
记录密码哈希： 当用户更改密码时，
pam_pwhistory.so
会截获新密码的哈希值，并将其添加到/etc/security/opasswd
文件中对应用户的历史记录中。这个文件是每个用户的旧密码哈希值的“档案馆”。 -
检查新旧密码： 在用户设置新密码时，
pam_pwhistory.so
会先从/etc/security/opasswd
中读取该用户存储的历史密码哈希值，然后将用户尝试设置的新密码进行哈希，并与历史记录中的每一个哈希值进行比对。 -
强制策略： 如果新密码的哈希值与历史记录中的任何一个哈希值匹配，模块就会拒绝这次密码更改请求，并通常会向用户显示一个错误消息，提示他们不能重复使用旧密码。这个行为由你在PAM配置文件中设置的
remember=N
选项控制，其中N
指定了要记住的最近密码数量。
这个模块通常被配置在PAM配置文件的
password堆栈中。
password堆栈是负责密码更改和管理操作的模块集合。例如，在
system-auth或
password-auth文件中，你可能会看到它与
pam_unix.so（处理实际密码存储和验证）和
pam_cracklib.so（用于检查密码复杂性）协同工作。
pam_cracklib.so
通常在最前面，负责检查密码强度（长度、大小写、数字、特殊字符等）。- 然后是
pam_pwhistory.so
，它检查新密码是否在历史记录中。 - 最后，
pam_unix.so
负责将通过所有检查的新密码写入/etc/shadow
文件。
这种模块化的设计使得管理员可以非常精细地控制密码策略，例如，你可以设置记住5个旧密码，也可以设置为10个，或者根本不启用历史记录（虽然不推荐）。通过将
pam_pwhistory.so放置在正确的位置并使用适当的控制标志（如
requisite），可以确保在密码不符合历史要求时，整个密码更改过程立即失败，从而有效阻止不安全密码的使用。
如何验证和排查/etc/security/opasswd配置的有效性？
配置完
/etc/security/opasswd相关的PAM策略后，仅仅保存文件是不够的，你得验证它是否真的按预期工作，并且在遇到问题时知道如何排查。这就像你给汽车做了保养，总得开出去跑两圈，听听有没有异响，看看仪表盘才放心。
验证有效性：
最直接的验证方法就是尝试更改用户密码并观察行为。
正常首次更改： 为一个普通用户（非root）设置一个新密码。
passwd
这个密码应该能够成功设置。尝试重复使用： 立即再次为同一个用户更改密码，这次尝试使用你刚刚设置的那个新密码。
passwd
如果配置生效，系统应该会拒绝这次更改，并显示类似“密码与旧密码过于相似”或“密码在历史记录中”的错误信息。如果你设置了remember=N
，那么你需要尝试N+1
次密码更改，才能再次使用第一个密码。检查
/etc/security/opasswd
文件： 这个文件是二进制格式的，不能直接用cat
查看内容，否则会看到乱码。但你可以检查它的存在、大小和修改时间来判断它是否被更新。ls -l /etc/security/opasswd
如果你看到文件大小有变化，或者修改时间是最新的，说明pam_pwhistory.so
模块正在写入数据。
排查常见问题：
如果配置没有生效，或者出现其他异常，以下是一些常见的排查思路：
-
检查PAM配置文件路径和语法：
- 你修改的是正确的PAM文件吗？是
system-auth
还是password-auth
？在某些系统上，system-auth
可能是实际生效的软链接目标。 pam_pwhistory.so
行是否位于password
堆栈中，并且在pam_unix.so
之前？顺序很重要。requisite
或required
控制标志是否正确？如果使用了sufficient
，即使pam_pwhistory.so
检查失败，后续模块也可能允许密码更改。- 有没有拼写错误？多余的空格或字符？PAM配置对语法非常敏感。
- 你修改的是正确的PAM文件吗？是
-
查看系统日志： PAM模块的错误或警告信息通常会记录在系统日志中。
- 对于基于Debian的系统（如Ubuntu）：
tail -f /var/log/auth.log
- 对于基于Red Hat的系统（如CentOS/RHEL）：
tail -f /var/log/secure
在尝试更改密码时，观察这些日志文件，看是否有pam_pwhistory
相关的错误信息。这通常能提供线索，比如权限问题、模块加载失败等。
- 对于基于Debian的系统（如Ubuntu）：
-
/etc/security/opasswd
文件权限： 虽然这个文件由PAM自动管理，但如果它的权限或所有权不正确，可能会导致pam_pwhistory.so
无法读写。- 确保文件所有者是
root
，组也是root
。 - 权限通常是
600
（只有root有读写权限）。ls -l /etc/security/opasswd
如果权限不正确，使用sudo chown root:root /etc/security/opasswd
和sudo chmod 600 /etc/security/opasswd
进行修复。
- 确保文件所有者是
-
SELinux或AppArmor： 在启用了SELinux或AppArmor的系统上，它们可能会阻止PAM模块访问
/etc/security/opasswd
文件，即使文件权限看起来是正确的。- 检查SELinux或AppArmor的审计日志（如
/var/log/audit/audit.log
或dmesg
输出），看是否有相关的拒绝访问消息。 - 如果发现是策略问题，你可能需要调整SELinux策略或AppArmor配置文件，但这通常超出了日常配置的范畴，需要更专业的知识。
- 检查SELinux或AppArmor的审计日志（如
其他PAM模块冲突： 虽然不常见，但如果PAM配置中有其他自定义或第三方模块，它们可能会与
pam_pwhistory.so
产生冲突。在这种情况下，尝试暂时禁用其他模块进行测试，以隔离问题。
通过这些步骤，你通常可以定位并解决
pam_pwhistory.so配置中遇到的问题，确保你的Linux系统密码历史策略能够健壮地运行。
