背景

近日项目中客户通过SSH免密登录使用我们的主机的STFP服务，主机使用Keepalived热备。在测试的时候发现，主机掉线VIP切到备机上后，备机无法免密登录。后经过一番折腾终于解决问题，过程比较有趣，遂记录下来，以备参考。

问题重现

• 预配置

生成公私钥对和配置的过程就不在赘述，章节省略，我就给出测试的机器配置

21是keepalived的VIP所在机器，会在11和12之间切换，一开始21指向11。

我们使用12来作为ssh客户端来访问21来开始整个过程

• 免密正常

正常情况下配置好免密后，12第一次访问21会提示，以后访问则直接进入。

[root@10_12 .ssh]# ssh root@10.0.10.21
The authenticity of host '10.0.10.21 (10.0.10.21)' can't be established.
RSA key fingerprint is 87:87:f0:2c:49:9e:03:a3:9a:80:9f:c9:90:f0:5d:e8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.10.21' (RSA) to the list of known hosts.
Last login: Sun Mar 18 04:55:24 2018 from 10.0.10.12
[root@10_11 ~]# exit
logout
Connection to 10.0.10.21 closed.
[root@10_12 .ssh]# ssh root@10.0.10.21
Last login: Sun Mar 18 04:56:51 2018 from 10.0.10.12
[root@10_11 ~]# exit
logout
Connection to 10.0.10.21 closed.

• 切换主机

这时候，如果把VIP 21从11机器切换到12机器上

[root@10_11 ~]# service keepalived stop
停止 keepalived：                                          [确定]

• 免密异常

然后再使用12访问21，就会提示以下错误信息

[root@10_12 .ssh]# ssh root@10.0.10.21
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
91:11:3a:62:6d:69:e9:07:05:88:de:ee:a8:d0:e5:8a.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1
RSA host key for 10.0.10.21 has changed and you have requested strict checking.
Host key verification failed.

问题分析

问题分析经过了如下过程：

1. 因为SFTP目录对权限要求很严格，最开始认为可能是SSH配置和SFTP默认目录权限问题。但是几经查找之后并没有发现主机和备机的差异之处，于是第一次尝试陷入了僵局。
2. 后来查看了主备机的SSH版本发现并不一致，觉得可能是版本太低不支持免密，但做了测试后，遂发现低版本的免密是可用的，遂这条路线也宣告失败。
3. 以上情况都尝试了，同事们也束手无策，问题陷入了僵局。
4. 归零，从头开始看。由于这个问题是客户报的，并不是我们自测出来，所以一开始并未仔细观察错误内容，遂联系客户仔细检查了客户发出的错误提示，也是就是本文中免密异常的提示部分，经过相关搜索最终发现了问题所在。

产生这个问题的主要原因是在于ssh的验证过程会引入远程机器指纹的校验。

我们在回头看免密成功时的第一次登录信息

[root@10_12 .ssh]# ssh root@10.0.10.21
The authenticity of host '10.0.10.21 (10.0.10.21)' can't be established.
RSA key fingerprint is 87:87:f0:2c:49:9e:03:a3:9a:80:9f:c9:90:f0:5d:e8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.10.21' (RSA) to the list of known hosts.

第一次登录某个主机时，ssh客户端会记录远程机器的RSA指纹，并写入~/.ssh/know_host文件中

[root@10_12 .ssh]# cat ~/.ssh/known_hosts 
10.0.10.21 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAy9M2k50qh6BIgqwP7A8kusrmUkDZKCC7W0EOjDxj+ZElmB+26weRDXoyj4c41w3hucDnM5Wo6q0J+xMxWPTHXoX/5H9WkUQGTDajndy6RFW84uuEVpVyE5UVugRvzL4x4M084ienqR4riIAF9ffL3TU+QJ6ow4fThTv+3phIaxgBJC+n4EoVPxfVFX5mKgahtcnwP/UBYu4i7Yjv5zY5oA54YpvBg8psCDdP1nK8LcrBwkARWxYNEnPFzJaAoy15vTe866eEGfqdqCnG7WzR6Fn2CYBipcm9rTI8Q8v6P2gwRHF/nelQfXBY593NMQdc6DfoIzdjwIKPQW5DLCf33Q==

如果远程的IP未变，但物理机器更换了，正如keepalived切换主备机时候一样，远程的机器的指纹其实发生了变化，我们再看免密异常的错误提示

[root@10_12 .ssh]# ssh root@10.0.10.21
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
91:11:3a:62:6d:69:e9:07:05:88:de:ee:a8:d0:e5:8a.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1
RSA host key for 10.0.10.21 has changed and you have requested strict checking.
Host key verification failed.

这个机器的指纹和我们第一次登录时候不一样了，所以根据ssh登录时的默认安全策略，拦截了这次的免密登录。

解决方案

既然问题找到了，那么如何解决这个问题呢。经过一番搜索，找到了一些解决办法

• 第一种：遗忘法

每次登录时把~/.ssh/known_hosts 删除，不过这个办法不好用来做自动化操作。

• 第二种：无视法

我们同样可以让ssh客户端不进行指纹检查和不记录指纹，但这样会降低一定的系统安全性

~/.ssh/config更新如下配置

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

~/.ssh/config权限要求是组和其他用户不能写，否则会失败，例如用户权限是664时，进行登录会有如下错误提示

[root@10_12 .ssh]# ll
总用量 16
-rw-r--r-- 1 root root  408 3月  18 04:33 authorized_keys
-rw-rw-r-- 1 root root   55 3月  18 06:08 config
-rw------- 1 root root 1675 3月  18 04:13 id_rsa
-rw-r--r-- 1 root root  408 3月  18 04:13 id_rsa.pub
[root@10_12 .ssh]# ssh root@10.0.10.21
Bad owner or permissions on /root/.ssh/config

如果出现这样的错误时，我们需要更改下权限即可。

[root@10_12 .ssh]# chmod 644 config

总结思考

这个问题花了很长时间解决，根本上的原因还是由于对ssh验证过程不熟导致。

问题分析过程也表明了，疑难问题要从长计议，不要忽视原始错误信息，可能会给我们带来很大帮助。

有些问题单独处理也许很简单，但结合了一些其他组件可能会变得复杂，要仔细观察问题表现，通过丰富的知识和经验中提取关键因素，再去解开表象从而达到问题本质，这时便迎刃而解

关于本问题其实还可能存在其他处理方式，例如让两机器的指纹一致，这时候需要修改机器指纹，如下文件

[root@10_12 ssh]# ll /etc/ssh
总用量 156
-rw------- 1 root root 125811 3月  22 2017 moduli
-rw-r--r-- 1 root root   2047 3月  22 2017 ssh_config
-rw------- 1 root root   3876 3月  18 04:40 sshd_config
-rw------- 1 root root    668 4月  17 2017 ssh_host_dsa_key
-rw-r--r-- 1 root root    590 4月  17 2017 ssh_host_dsa_key.pub
-rw------- 1 root root    963 4月  17 2017 ssh_host_key
-rw-r--r-- 1 root root    627 4月  17 2017 ssh_host_key.pub
-rw------- 1 root root   1675 4月  17 2017 ssh_host_rsa_key
-rw-r--r-- 1 root root    382 4月  17 2017 ssh_host_rsa_key.pub

但由于这些文件都是ssh验证过程的基础，直接修改会不会导致问题或者组件失效，我也没办法保证也没有去研究，如果有感兴趣的同学们可以去试一试