Windows节点GIT_SSH认证失败问题排查求助

从你给出的日志来看，核心错误是gituserfromcredbinding@bitbucket.org: Permission denied (publickey)——这说明失败节点的SSH认证环节出了问题，哪怕两台节点配置步骤看起来一致，肯定有一些容易忽略的细节差异。下面是我遇到类似问题时的排查步骤，按优先级排序：

1. 确认Jenkins节点运行的用户及其SSH目录 #

Windows下Jenkins节点的运行用户是关键：

• 如果是通过JNLP以当前桌面用户启动：SSH密钥会存在该用户的C:\Users\<你的用户名>\.ssh目录下
• 如果是以Windows服务运行：默认用Local System账户，它的家目录是C:\Windows\System32\config\systemprofile\.ssh

你可以：

• 打开失败节点的Jenkins管理页面，查看节点的"Launch method"确认运行用户
• 切换到对应用户，检查.ssh目录下是否有Jenkins凭证对应的密钥（或者Jenkins通过GIT_SSH临时生成的密钥是否能被该用户访问）
• 手动执行ssh git@bitbucket.org，看是否能成功连接（第一次连接会要求确认主机指纹，需要手动同意）

2. 模拟Jenkins的Git操作，直接在节点上测试 #

在失败节点上，切换到Jenkins运行的用户，执行以下命令完全模拟流水线的克隆操作：

git init C:\Jenkins\workspace\test-slave123456
git fetch --tags --progress git@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/origin/*

如果这一步也失败，说明问题出在节点的Git/SSH环境，和Jenkins流水线无关；如果成功，那就要检查Jenkins的节点配置（比如环境变量传递、权限限制）。

3. 检查Git的凭证助手配置 #

虽然你说关闭了Windows凭证存储，但可能全局配置里还有残留：
执行git config --global credential.helper，如果输出是wincred或者其他凭证助手，会干扰SSH的公钥认证。可以用以下命令清空：

git config --global --unset credential.helper

4. 验证Git使用的SSH客户端 #

Windows下可能同时存在多个SSH客户端（Git自带的、系统OpenSSH），Jenkins调用的可能不是你预期的那个：

• 执行where ssh，看输出的路径，对比正常节点的结果
• 检查Jenkins节点的环境变量，是否设置了GIT_SSH指向正确的ssh.exe（比如Git安装目录下的usr\bin\ssh.exe）

5. 检查主机密钥验证 #

失败节点可能没有Bitbucket的主机指纹，导致Jenkins无头运行时无法交互确认：

• 手动在节点上执行ssh git@bitbucket.org，当提示"Are you sure you want to continue connecting (yes/no/[fingerprint])?"时输入yes，这样指纹会被写入known_hosts文件
• 或者在Jenkins的Git插件配置里，临时开启"Accept first connection"选项（仅用于测试，不推荐长期使用）

6. 检查Windows权限和目录访问 #

• 确认Jenkins运行用户对C:\Jenkins\workspace目录有读写权限
• 检查Git安装目录的权限，确保该用户能执行git.exe和ssh.exe

7. 对比两台节点的Git版本 #

虽然日志里都执行了git --version，但不同版本的Git在Windows下的SSH处理可能有差异。对比两台节点的Git版本，如果不一致，尝试升级/降级到相同版本再测试。

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