在做大批量运维的时候，DBA 需要掌握和使用 ansible。今天有同事使用 ansible 遇到了一个奇怪现象，和我交流了一下，我发现这个现象很奇怪，也很有趣，我认为是个 BUG，于是排查，之后有了这篇文章。

同事使用的是 ansible2.7.8，我使用的是最新版 python3.11+ ansible2.14，我们都复现了这个现象。这个问题简而言之是，使用比较特殊的密码组合作为主机密码，ansible 在使用上会遇到问题，导致正确的密码而无法连接。

以下是我的环境：

同事疑问1——特殊密码，ansible无法连接会报错

同事设置了一个形如”1#xxxxxx”的密码，使用 ssh [email protected] 连接是完全没有问题的，但使用 ansible 连接则会报错，”Invalid/incorrect password: Permission denied, please try again.” 无法连接。这个密码经过我的研究，是有规律，1位到任意长度的数字 + ‘#’ + 任意长度字符，ansible 会报错。

也就是，以下密码会报错

• 1#fander
• 12#fander

以下密码不会报错

• 1a#fander
• 1@fander

同事疑问2——此特殊密码，ansible无法连接会报错，但有时却能连接不报错

1. ansible -vvvvv 排查

​​-v​​参数可以让 ansible 输出 debug 日志，v 越多越详细。当然了，可能并不需要五个 v，我不知道要打多少个 v 时，我就把 v 打满。( mysqlbinlog 我打 3个 v )

如图红圈和横线，这两处很关键。

红圈告诉我，我在执行 ansible 时，其实底层调用的是 sshpass 和 ssh。

横线这一处，报有个文件不存在，我对比了执行正常连接的机器(192.168.199.131)，是不会报这个的，所以此处属于异常，需要排查。

这些日志输出其实一团糟，可以粘贴到 notepad++，用以下方法美化输出。

粘贴到 notepad++ 只有两行，通过替换 \r\n 为换行符即可。

首先，我先把 \r\n 替换为 fanderissb

然后，再以扩展模式，替换回来

现在就比较好阅读了，这一处就是不正常的。

经过研究，这些 debug 日志其实来源于我前面红圈的命令行 sshpass xxx 的输出。

查阅资料和整理，原理大概是这样的：

正确连接是长这个样子的，命令结果是输出”/root\n”，前面的 0 是命令 ​​$?​​ 的返回码，0 代表执行正常。

而我们密码有问题的服务器返回码是 5，输出是空

在这句命令中，​​Cnotallow=60s​​ 是 ssh 的参数，代表建立一个长链接，保持 60 秒，这个长链接就是建立在 ​​Cnotallow=/root/.ansible/cp/e2f9f7759b​​ 的路径下。

实际上，就是这个 ​​ControlPersist​​，可以解答同事疑问2——此特殊密码，ansible无法连接会报错，但有时却能连接。

为了方便解释，我把 ansible 服务器的这个 ​​ControlPersist​​ 调大到 600 秒。

首先，我登录远端服务器，先把密码改回常规密码。

接着，我配置好 ansible 服务器的 hosts 文件。

然后，开始测试。完全没有问题，能连通。

执行 ​​ps -ef​​ 能观察到，我们第一次连接完后，ssh 并没有断开，有一个背景执行的长链接，他实际上是一个多路复用的 socket 连接，后续我们再连远端服务器时就是复用他，不需要重新验证密码。

这个时候，我把远端的服务器密码修改为有问题的密码

此时，我的 ansible 服务器的 hosts 配置里仍然用的旧密码

密码是错误的，那么我还能连吗？答案是——能。这就是连接复用，不需要重新验证密码，直接复用前面的 socket 连接。

所以，这时你通过 ansible，密码乱输或者不输密码都能连。

那么这个长链接是创建后的 600 秒自动销毁吗？(提醒，前面我修改的Cnotallow=600s)

答案——否。因为我在创建连接后，中途复用过这个连接通道，时间是 22:49:15，所以他消失时间不是创建时间 22:40:28 + 10 分钟，而是 22:49:15 + 10分钟，也就是 22:59:15。

那同事的疑问2，就可以解释了，有问题的密码依然不能通过 ansible 连接，能连接的假象是因为曾经用正确的密码建立过长链接(这个是 ssh 的参数功能，不是 ansible)，后面连接时复用了此连接，没有使用密码认证，所以也就不会报错了。待 ​​ControlPersist​​ 超时后，socket 销毁，有问题的密码连接就开始报错了。

我们继续排查同事的疑问1。

根据我前面整理的原理，我标记1、2、3、4数字的这几步，我按这个顺序从下往上开始一一排除。

其实，本来应该从最顶上的 4 开始排查的，但 4 需要阅读源码，所以我从简单的 1 开始排查。

2. 排查 ssh

首先，我测试标记为 1 的步骤，手敲这个密码，ssh 是否认正常。结果是连接正常。

3. 排查 sshpass

然后，测试标记为 2 的步骤，测试 sshpass 传输密码是否正常的。结果也是连接正常。

这里，我调整了原命令，因为原命令用的是 sshpass -d10，这个文件描述符文件我不知道如何制造，所以我改为用 sshpass -p 来测试。我去掉了 -vvv ，因为如果一切正常，我不需要刷屏的 debug 日志。

4. 使用 paramiko 连接方式辅助排查

标记为 3 的步骤，我不知道如何测试，但我知道 ansible 除了 ssh 连接，还有一种叫 paramiko 的连接方式，他是旧版 ansible 的默认连接方式，他比较低效，他不使用 ​​ControlPersist​​，也就不会建立 ​​Control socket​​，而之前我们连接报错时，日志的关键信息就是​​Control socket "/root/.ansible/cp/e2f9f7759b" does not exist​​

当然了，他也不会使用 sshpass 和不会把密码写入那个数字为 10 的文件描述符。所以，如果我能在  paramiko 的连接方式能复现报错，那么就和标记为 3 的步骤无关。

结果是，我使用 paramiko 的连接方式，也能复现连接报错。

他这个 python 抛出异常非常好，终于让我知道为什么密码会错误了，原来传进去的密码不是”1#fander”，而是”1”。也就是问题肯定不在标记为 3 的步骤，而是标记为 4 的步骤。

根据报错，我在 auth_handler.py 文件里打了两个 print。

我们再看看输出。

那么，标记为 1、2、3 的步骤我们都排除了，问题出在标记为 4 的步骤，也就是现在的问题是：

为什么 ansible 传入给 sshpass 和 ssh 的密码不正确，应该传入”1#fander”，但最终传入”1” ？

5. 排查 ansible -k

我们再来做个测试，不使用 ansible hosts 文件传递密码，使用 ​​-k​​ 参数手敲密码。发现一切正常。

6. 水落石出，是 ansible 的 hosts 设置问题

那问题完全能定位出来了，这个疑似 bug，不是 ssh 也不是 sshpass 的问题，而是 ansible 的问题。并且，我们能确定，这个和 ansible 读取解析 /etc/ansible/hosts 文件有关。

经过我查阅资料，ansible 读取解析 /etc/ansible/hosts 相关的代码在这个路径下，​​ini.py​​ 文件。

通过阅读注释，发现这个不是 bug，而是官方知道的问题，所以属于一个坑。

我经常阅读源码都是通过阅读注释就解决的，这很有趣，适合我这种萌新 coder。现在是 2022 年 11 月 13 日的 23:56 分，由于能力和时间的关系，我就写到这里了。大家应该看懂了解决办法，请大家避免这个坑，这个坑不单止针对密码，在 hosts 文件的所有变量设置都应该这么做(上图横线)。有兴趣深入研究的同学可以继续看看源代码。

来源：本文转自公众号芬达的数据库学习笔记，​ ​点击查看原文​​。