背景

我们在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 - tidb
cp ～/.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 - tidb
tiup cluster reload $cluster_name

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

总结及建议

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