pam_unix(sudo:auth)：对话失败，auth 无法识别 [username] 的密码

Posted 2023-03-10

【中文标题】pam_unix(sudo:auth)：对话失败，auth 无法识别 [username] 的密码

【英文标题】：pam_unix(sudo:auth): conversation failed, auth could not identify password for [username]

【发布时间】：2019-12-30 15:06:37

【问题描述】：

我正在使用 ansible 来配置我的 Centos 7 生产集群。不幸的是，使用 ansible Tiemout 和 Linux Pluggable Authentication Modules (pam) error conversation failed 执行以下命令。

同样的 ansible 命令运行良好，在 vagrant 盒子里疯狂地执行虚拟实验室。

Ansible 命令

$ ansible master_server -m yum -a 'name=vim state=installed' -b -K -u lukas -vvvv
123.123.123.123 | FAILED! => 
    "msg": "Timeout (7s) waiting for privilege escalation prompt: \u001b[?1h\u001b=\r\r"

SSHd 日志

# /var/log/secure
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): conversation failed
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): auth could not identify password for [lukas]

【问题讨论】：

对不起，如果这个问题看起来很愚蠢，但只是为了仔细检查：你在启动你的 ansible 命令时得到BECOME password: 提示吗？你在那里输入了 sudo 的通行证吗？

没有愚蠢的问题 :) 是的，我做到了。

【参考方案1】：

我发现了问题。原来是PAM'sauth模块问题！让我描述一下我是如何找到解决方案的。

上下文：

我设置了我的机器进行调试 - 即我打开了四个终端窗口。

第一个终端

（本地机器）：在这里，我正在执行ansible prduction_server -m yum -a 'name=vim state=installed' -b -K -u username

第二个终端

（生产服务器）：在这里，我执行了journalctl -f（系统范围的日志）。

第三个终端

（生产服务器）：在这里，我执行了tail -f /var/log/secure（sshd 的日志）。

第 4 个终端

（生产服务器）：在这里，我正在编辑 vi /etc/pam.d/sudo 文件。

每次，我从 第一个终端执行命令时都会收到以下错误：

# ansible error - on local machine
Timeout (7s) waiting for privilege escalation prompt error.

# sshd error - on remote machine
pam_unix(sudo:auth): conversation failed
pam_unix(sudo:auth):  [username]

我向我的同事展示了我的整个设置，他告诉我该错误与 “PAM” 有关。坦率地说，这是我第一次听说PAM。所以，我不得不阅读这个PAM Tutorial。 我发现，该错误与位于 /etc/pam.d/sudo 模块中的 auth 接口有关。通过互联网挖掘，我偶然发现了这个带有sufficient 控制标志的pam_permit.so 模块，这解决了我的问题！

解决方案

基本上，我添加的是auth sufficient pam_permit.so 行到/etc/pam.d/sudo 文件。看下面的例子。

$ cat /etc/pam.d/sudo
#%PAM-1.0
# Fixing ssh "auth could not identify password for [username]"
auth       sufficient   pam_permit.so

# Below is original config
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth

结论：

我花了 4 天时间才得出这个解决方案。我偶然发现了几十个对我不起作用的解决方案，从 “ansible hosts/config 文件中的 sudo 密码重复”、“ldap 特定配置” 到获得建议来自总是脾气暴躁的系统管理员！

注意：

由于我不是 PAM 方面的专家，我不知道此修复是否会影响系统的其他方面，因此请小心盲目复制粘贴此代码！但是，如果您是 PAM 专家，请与我们分享替代解决方案或输入。谢谢！

【讨论】：

添加后，我可以在命令行中使用 sudo 而无需密码。我看到了与您相同的问题，但其他人应该知道这将禁用 sudo 安全性（确实消除了错误！）

感谢比尔的输入，非常感谢。

如果有帮助，几个小时后我发现我的错误是由于 /etc/sudoers.这些文件以 ASCII 顺序加载，后来的“ALL”掩盖了之前出现的 NOPASSWD: /path/to/command。我将限制性更强的文件重命名为 00_filename，然后我们都遇到的错误消息消失了！不知道我们是否有同样的问题。

所以毕竟它看起来像 sudo 安全性，与 PAM 无关。我写这个答案已经快一年了，不记得我这边的 sudo 用户没有密码访问。感谢您澄清这一点。

通过这样做，您基本上可以跳过所有身份验证步骤并授予访问权限。不是生产服务器的安全步骤。

【参考方案2】：

假设 lukas 用户是本地帐户，您应该查看 pam_unix.so 模块在您的 system-auth 中是如何声明的pam 文件。但是对于特定的答案，需要有关用户帐户和 pam 配置的更多信息。

---

虽然添加 auth 足够的 pam_permit.so 就足以获得访问权限。不建议在最不安全的测试环境中使用它。从 pam_permit 手册页：

   pam_permit is a PAM module that always permit access. It does nothing
   else.

因此，以这种方式将 pam_permit.so 添加为 足够 进行身份验证将完全绕过所有用户的安全性。

【参考方案3】：

发现自己处于同样的境地，头发都被扯掉了。在我的情况下，隐藏在 sudoers 文件的末尾，有一行：

%sudo ALL=(ALL:ALL) ALL

这会撤消之前的授权。如果您不使用 sudo 组，则可以安全地删除此行。

【参考方案4】：

当我尝试使用 sudo service apache2 restart 重新启动 apache2 时遇到同样的错误

登录到 root 时，我能够看到真正的错误在于 apache2 的配置。结果我几个月前删除了一个站点的 SSL 证书文件，但没有在 apache2 中禁用该站点。 a2dissite 成功了。

【讨论】：

运行 apache 服务和损坏的 ssl 证书与 pam_unix 无关。问题比这更根本。仅在 apache 中禁用站点不太可能对此问题产生任何影响。因此，我对您的回答投了反对票。

恕我直言，这使我的回答更加有效。是的，显然 PAM 的 auth 模块存在根本问题，但许多其他遇到此问题的人可能更愿意避免接触它并首先找到导致错误的原因，即使缺少正确的错误消息（此线程在 Google 上是 #1对于 PAM 的错误消息）。在我的情况下，它在 apache 配置中丢失了文件，显然对于其他人来说可能是别的东西。然而，对于许多人来说，这正是发生在基本 LAMP 安装上的情况。所以不，我不接受你的反对票；）

此页面是参考Apache查找此错误时的第一个结果，此评论为正确答案。对于这些情况，问题在于 Apache 的配置，而不是特定于 SSL。不要为 Apache 配置问题修改 PAM 许可。

支持“以 root 身份运行 apache2 时获得不同的错误消息”

【参考方案5】：

自从使用 pacman 将 sudo 升级到 1.9.4 版后，我遇到了这个错误。我没有注意到 pacman 提供了一个新的sudoers 文件。

我只需要合并/etc/sudoers.pacnew。 更多详情请看这里：https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave

我知道这不能回答最初的问题（与 Centos 系统有关），但这是错误消息的最佳 Google 结果，所以我想我会把我的解决方案留在这里以防万一有人偶然发现这个问题来自基于 Arch Linux 的操作系统。