使用hosts: localhost和delegate_to导致Kerberos UNREACHABLE错误排查

这种情况我之前碰到过好几次，大概率不是Bug，而是Tower GUI和命令行环境在Kerberos认证上下文或者变量传递逻辑上的差异导致的。咱们一步步拆解可能的问题点：

1. Kerberos认证的上下文差异 #

命令行运行时，你是用当前登录用户的Kerberos Ticket来完成Windows主机认证的；但Tower GUI执行Playbook时，是用Tower配置的执行账户/凭据来运行的。这里可能存在两个问题：

• Tower的Windows凭据没有关联有效的Kerberos Keytab，或者凭据的权限不足以访问comp1.private.net；
• 你的本地命令行环境缓存了有效的Kerberos Ticket，但Tower的执行节点（Runner）没有对应的缓存，也没有自动获取Ticket的逻辑。

排查/解决方法：

• 检查Job Template中配置的Windows凭据，确认其Kerberos相关配置（比如Keytab路径、域用户权限）正确；
• 在第三个Play中添加前置任务，手动为Tower执行账户获取Kerberos Ticket：

  - name: 获取Kerberos Ticket
    command: kinit -kt /path/to/keytab-file user@DOMAIN.COM
    delegate_to: localhost
    run_once: true
  

2. Inventory变量传递的差异 #

命令行里你指定了-i inventory/inventory，但Tower GUI的Job Template可能没有使用完全相同的Inventory配置，或者Tower自动添加的变量覆盖了你的自定义配置。重点检查以下Windows连接变量：

• ansible_winrm_transport: 是否设置为kerberos；
• ansible_winrm_kerberos_delegation: 如果需要委派认证，必须设为true；
• ansible_winrm_server_cert_validation: 如果目标主机用自签证书，需设为ignore。

排查/解决方法：

• 对比Tower Inventory和本地Inventory的变量配置，确保关键WinRM参数一致；
• 在win_stat任务中显式指定连接变量，排除Tower变量优先级干扰：

  - name: 检查comp1上的文件
    win_stat:
      path: C:\target-file.txt
    delegate_to: comp1.private.net
    vars:
      ansible_connection: winrm
      ansible_winrm_transport: kerberos
      ansible_winrm_kerberos_delegation: true
      ansible_winrm_server_cert_validation: ignore
  

3. Tower执行节点的环境限制 #

Tower的Runner主机可能和你的本地命令行环境不在同一个域环境中，或者Kerberos配置文件（krb5.conf）存在差异：

• Runner主机的DNS解析是否能正确识别comp1.private.net的域身份；
• krb5.conf中的Realm、KDC服务器配置是否和你的本地环境一致。

排查/解决方法：

• 登录到Tower的Runner主机，用Tower执行账户手动执行ansible comp1.private.net -m win_ping，看是否能成功；
• 对比Runner主机和本地的krb5.conf配置，修正不一致的地方。

4. Delegate_to的上下文优先级问题 #

当在localhost上使用delegate_to时，Tower可能会错误地将localhost的连接变量应用到委派目标主机上（虽然理论上不应该，但实际中偶发）。

排查/解决方法：

• 尝试将第三个Play的目标主机直接设为comp1.private.net，而不是通过localhost委派，看是否能正常执行；
• 如果必须用委派，确保Play中明确指定目标主机的变量优先级高于全局变量。

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