作者： cchouqiang 原文来源：https://tidb.net/blog/7a6ebd3d

背景

我们在 TiDB 上进行集群操作常用的命令就是 tiup，但是经常会遇到如下报错：

ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

从报错来看，可能是由于两台机器之间互信出问题导致的，但这只是表象，我们需要刨根问底，找到问题的根本原因。

排查思路

执行 tiup 报错“ssh: unable to authenticate”，排查方向如下：

当 tiup 执行报错时，我们从以下几点去排查：

1、报错的机器是否可以连通，若连不上，可能是机器出现故障，需要去解决机器问题；

2、如果机器可以连接，检查机器的互信是否可用，通过 ssh ip date 命令检查，若改命令报错，则需要配置互信；

3、如果机器互信正常，进一步检查 tiup 目录下的 id_rsa 跟家目录下的 id_rsa 是否相同，若不相同，则需要把家目录下的 id_rsa 拷贝到 tiup 目录下；tiup 的 id_rsa 路径为：/home/tidb/.tiup/storage/cluster/clusters/tidb-test/ssh/id_rsa

4、检查机器的 sudo 权限，由于安全策略，可能会把 sudo 权限收回，tiup 执行 stop 等命令也会报错。

故障案例

tidb 集群进行扩容

遇到报错如下：

ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

分析扩容日志，发现是‘Refresh instance configs’报错：

检查集群状态

发现新加的 tikv 已经加入到集群中，最后三个 tikv 节点是新扩容的。

手动触发更新配置

由于是‘Refresh instance configs’时报错，手动执行 tiup cluster reload 命令，触发更新配置，依旧报错，无法更新配置至其他节点。

手动执行报错命令

将上图中的报错命令，在 tiup 节点手工执行，发现可以执行成功。

测试集群间的互信

测试 ssh ip，不需要输入密码就可以登入成功，则说明互信没问题。

测试 ssh -i 密钥

测试 ssh -i id_rsa IP 时，登入需要密码，则说明 tiup 使用的密钥有问题。

检查～/.ssh 和 tiup 下的 ssh 目录下的密钥

经过对比发现，tidb 用户家目录下的.ssh 密钥是被更新过的，跟 tiup 下 ssh 目录密钥不一致，问题已水落石出。

故障处理

更新 tiup 下的密钥

将～/.ssh/id_rsa 拷贝到 tiup 下的 ssh 目录下

su - tidbcp ～/.ssh/id_rsa ～/.tiup/storage/cluster/clusters/tidb-test/ssh

扩容 tikv 集群

重新执行扩容操作，‘Refresh instance configs’已经通过，证明更新 tiup 下的密钥是有效的；

一波三折，又出现了新问题，报错如下：

解决‘systemctl enable node_exporter-9100.service’失败问题

手动执行报错命令，报错如下：

从报错可以看出 node_exporter-9100.service 文件不存在了，此时需要重新生成该文件。

使用 tiup cluster reload 命令，可以重新生成该文件：

su - tidbtiup cluster reload $cluster_name

至此，上面出现的问题已解决，tikv 扩容成功。

总结及建议

  tidb集群在进行扩缩容时，需要更新配置文件到其他节点，此时使用的是tiup中的ssh/id\_rsa密钥，而并不是节点间配置的互信；本次问题的根因是\~/.ssh密钥更新了，而并没有将tiup的ssh目录更新，tiup无法将配置文件下发到其他节点。