TiDBv8.5.0集群组建失败executor.ssh.execute_failed

TiDBer_tPmU5BOm · 2026 年8 月 5 日 10:25

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境
【TiDB 版本】8.5.0
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】UOS 1070e/Hygon C86-4G (OPN:5480)
【机器部署详情】2*32核/128G/15T
【集群数据量】
【集群节点数】3
【问题复现路径】组件集群报错/root/.tiup/bin/tiup cluster check /home/service/tidb/topology.yaml --user root
【遇到的问题：问题现象及影响】
【资源配置】
【复制黏贴 ERROR 报错的日志】
执行check和直接执行安装都是失败

【其他附件：截图/日志/监控】

TiDBer_tPmU5BOm · 2026 年8 月 5 日 11:44

tiup报错ssh功能有问题，没有办法去执行成功ssh

克里克里克 · 2026 年8 月 5 日 13:30

密码不一致吧。要不配置下互信试试。

kang · 2026 年8 月 6 日 00:30

看截图报错是 executor.ssh.execute_failed，这是典型的 SSH 连接或执行权限问题。建议按以下顺序排查：

确认免密登录：执行 ssh root@目标IP 手动测试，确保 tiup 所在机器能免密登录所有节点。

TiDBer_tPmU5BOm · 2026 年8 月 6 日 01:07

已经配置了，ssh到集群任意节点都无异常

TiDBer_tPmU5BOm · 2026 年8 月 6 日 01:08

免密、测试ssh都执行无异常

独善其身 · 2026 年8 月 6 日 01:47

手动 ssh root 可以免密登录所有节点
UOS 开启 root 远程 ssh 登录权限
安装系统依赖、关闭防火墙与 SELinux
校验拓扑 yaml 配置、部署目录权限
更新 tiup 组件，重新执行集群检查

TiDBer_bawpguhQ · 2026 年8 月 6 日 02:05

executor.ssh.execute_failed 多半是 SSH 免密、端口、SELinux/防火墙或目标机命令权限问题。先对本机到各节点手动 ssh 与 sudo；核对 topology 用户/密钥路径，再重跑 check。

Loving · 2026 年8 月 6 日 07:12

从日志看并非 TiDB 组件故障，主要是控制机到 192.168.151.11 的 root SSH 免密认证失败（公钥签名校验失败/无可用认证方式），应先检查 authorized_keys、文件权限及 SSH 算法兼容性，同时重新安装或升级 TiUP 以排除其 panic 异常。

wbslxw · 2026 年8 月 6 日 11:16

UOS 系统 OpenSSH 新版本默认禁用 ssh‑rsa 签名算法，TiUP 内置 golang ssh 库仅支持 rsa‑sha1，双方没有匹配的签名算法，SSH 握手直接失败

认证小秘书 · 2026 年8 月 15 日 11:25

从报错来看，其实可以先不用怀疑海光 CPU 或 UOS 兼容性问题，前面的 CPU 架构和操作系统检测都是 Done，说明基础环境是正常的。问题出在 TiUP 收集系统信息这一步 SSH 认证没有通过，关键报错是 ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain。

你现在的命令只指定了 --user root，但没有提供密码或者 SSH 私钥，所以 TiUP 在连目标机器时没有可用的认证方式。可以先在中控机上手动试一下 ssh root@192.168.151.11，看看能不能直接登录。

如果三台机器是用 root 密码登录的方式，可以改用 tiup cluster check /home/service/tidb/topology.yaml --user root -p，然后按提示输入密码即可。

如果是走 SSH 免密登录，那就需要确认中控机的公钥已经正确写入三台服务器的 /root/.ssh/authorized_keys，同时也可以在命令里显式指定私钥，比如 -i /root/.ssh/id_rsa，避免 TiUP 找不到可用 key。

这个报错在 TiUP 的排查文档里也有对应说明，本质上就是没有找到可用的 SSH 认证方式，或者指定的私钥无法完成登录。

另外在 UOS 上也可以顺手看一下 /etc/ssh/sshd_config 里的 PermitRootLogin 配置，如果 root 被禁止远程登录，那就不要继续用 --user root 了，换一个可以 SSH 登录、并且具备 sudo 权限的普通用户来执行 cluster check 会更稳妥。