Rundeck执行Windows节点PowerShell脚本失败：脚本复制失败（主机未找到）

我之前也碰到过类似的Rundeck+Windows OpenSSH节点的SCP分发故障，结合你描述的场景——手动scp能正常工作、已通过Kerberos域用户认证且能执行命令，但作业内脚本分发失败，给你几个针对性的排查和修复方向：

1. 核对Rundeck节点配置的格式 #

你手动执行的scp命令用的是rundeck@test.com@WIN-II425CK1GMO.test.com，但错误日志里显示的是TEST.COM@192.168.0.13，这很可能是节点配置的格式错误：

• 确保节点配置的username字段单独填写域用户rundeck@test.com，hostname字段填写WIN-II425CK1GMO.test.com或192.168.0.13，不要将用户名和主机名拼接成一个字符串。
• 确认ssh-port参数设置为22（Windows OpenSSH默认端口），避免端口配置错误导致连接失败。

2. 修正SCP目标路径格式 #

Windows OpenSSH对路径的解析和Linux略有差异，你手动用的/C:可能不符合jsch-scp的解析逻辑：

• 在Rundeck作业的脚本分发设置中，将目标路径改为POSIX风格的路径，比如/C/temp/（提前确保C:\temp目录存在且有读写权限），而非/C:。
• 可以在节点配置中添加参数：ssh-scp-destination-path-style=posix，强制Rundeck使用POSIX路径格式适配Windows OpenSSH。

3. 验证Kerberos票据有效性 #

虽然能执行命令，但脚本分发操作可能需要重新校验Kerberos票据：

• 检查Rundeck服务运行用户是否持有有效的Kerberos票据，手动执行kinit rundeck@TEST.COM刷新票据后再测试作业。
• 确认krb5.conf中的域Realm配置大小写正确（Kerberos对Realm大小写敏感），比如TEST.COM的配置是否准确映射到对应的KDC服务器。

4. 开启SSH调试日志定位细节 #

如果以上方法都无效，开启Rundeck的SSH调试日志可以帮你找到具体问题：

• 修改Rundeck配置文件rundeck-config.properties，添加或修改：

  log4j.logger.com.dtolabs.rundeck.core.execution.ssh=DEBUG
  

• 重启Rundeck服务后，查看/var/log/rundeck/rundeck.log中的SSH相关日志，就能看到jsch-scp执行的具体命令、路径和认证细节，定位到底是哪一步出了问题。

你遇到的错误提示参考：
TEST.COM@192.168.0.13 脚本分发至节点DC失败：[jsch-scp] 复制文件失败：TEST.COM@192.168.0.13 执行失败...

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