修改SSH端口后Ansible连接报“Invalid argument”的原因及疑问

场景概述 #

在Windows的WSL Ubuntu环境中运行Ansible，目标主机采用用户名密码认证，修改SSH默认端口并重启后，Ansible无法连接目标主机，报错：

ssh: connect to host ansiblepi1 port 10000: Invalid argument

已发现两种规避方法：

• 每次执行ansible-playbook前先运行ansible all -m ping
• 执行chmod -x .vault-pass（推测文件默认带+x权限是Windows与WSL交互导致）

1. 报错的根本原因 #

根本原因是vault密码文件.vault-pass被设置了可执行权限（+x），违反了Ansible对该文件的安全权限限制。

Ansible为了安全性，要求vault密码文件的权限必须严格限制（通常仅允许所有者可读，不能有任何执行权限）。当该文件带有+x权限时，Ansible会拒绝读取该文件，进而导致内部配置加载流程异常，最终干扰SSH连接的参数处理逻辑，表现为端口连接失败。

而WSL与Windows的文件系统交互特性，会导致在Windows侧创建的文件，在WSL Ubuntu中默认继承可执行权限，这就是.vault-pass出现+x权限的触发点。

2. 错误信息与实际问题偏差大的原因 #

这是因为Ansible的错误处理流程存在链路传递偏差：

• 当Ansible加载vault密码文件时遇到权限错误，这个底层错误没有被直接捕获并明确上报给用户。
• 错误会干扰后续SSH连接模块的初始化流程，导致Ansible无法正确处理ansible_port等连接参数，最终让SSH客户端抛出“Invalid argument”的错误，将问题误导到端口连接层面，掩盖了真正的vault文件权限问题。

验证与修复建议 #

直接修复方法是确保.vault-pass的权限符合安全要求：

chmod 600 .vault-pass

（设置为仅所有者可读可写，无任何执行权限，比单纯去掉+x更严格，完全适配Ansible的安全规则）

而提前运行ansible all -m ping能规避的原因是：执行ping命令时，Ansible会直接触发vault配置的加载检查，此时可能输出更明确的权限错误提示（如ERROR! Vault password file .vault-pass is world executable or readable），或者在错误处理后重置了内部配置状态，使得后续playbook执行时能正常加载vault配置。

内容的提问来源于stack exchange，提问作者Max