作者： cchouqiang
背景
我们在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无法将配置文件下发到其他节点。
