Ansible Vault加密SSH密钥失效及reset_connection影响咨询

Ansible Vault加密SSH密钥的内部工作机制 #

Ansible Vault并不直接加密SSH私钥文件本身，它只负责加密Ansible管理的变量或文件内容：

• 当你在清单中配置加密的SSH私钥路径时，实际是把ansible_ssh_private_key_file这个变量的值用Vault做了加密处理。
• Ansible执行任务时，第一步会先解密这个Vault加密的变量，得到真实的私钥文件路径。
• 随后Ansible调用系统的SSH客户端（比如OpenSSH），由SSH客户端读取该路径下的私钥文件完成身份验证、建立连接。
• 关键注意：如果直接用Vault加密私钥文件本身，SSH客户端是无法识别的——因为Vault加密后的文件带有专属格式头（比如$ANSIBLE_VAULT;1.1;AES256），完全不符合OpenSSH要求的私钥格式规范。

重置连接后密钥格式失效的原因 #

结合你遇到的LF/CRLF换行问题，核心原因和连接重置后的流程直接相关：

• 第一次转换为LF格式后能正常执行，说明原本的私钥文件是Windows换行（CRLF），OpenSSH读取时会把额外的换行符识别为密钥内容的一部分，从而触发"invalid format"错误——OpenSSH严格要求私钥文件使用Unix LF换行。
• 执行ansible.builtin.meta: reset_connection后，Ansible会销毁当前SSH连接会话，重新触发连接建立流程，此时出现错误大概率是以下情况：
  1. Playbook中存在重置连接前修改私钥文件的任务（比如自动备份、同步文件等），导致已经转成LF的文件又被改回CRLF格式。
  2. 少数场景下，Ansible重置连接时会重新读取清单变量并解密，若解密过程中因环境配置问题，指向了未转换格式的私钥副本（比如临时缓存的旧文件）。
  3. SSH客户端本身的缓存机制残留了之前的错误密钥状态，重置连接后重新读取文件时触发格式校验失败。

实用排查方向 #

• 用file 密钥路径命令检查重置连接前后的私钥文件格式，确认是否被意外修改。
• 确保私钥文件永久转为LF格式：执行dos2unix 密钥路径，或在编辑器中设置默认保存为LF。
• 避免直接加密私钥文件，始终加密ansible_ssh_private_key_file变量的值，确保SSH客户端读取的是原始合法格式的私钥。

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