云主机的普及率正在不断扩大，越来越多的企业、个人都在用云服务器。但是在使用的过程中，难免会出现这样那样的问题，遇到问题就一定是服务器坏了吗?那可不一定，具体问题还得具体分析。

　　下面，一起看看当ssh连接云主机出现故障，应该怎么解决。

　　ssh连接接云主机：

　　ssh root@123.59.xx.xx

　　报错：THE AUTHENTICITY OF HOST XX CAN’T BE ESTABLISHED

　　解决办法：

　　ssh -o StrictHostKeyChecking=no root@123.59.xx.xx

　　输入密码，链接成功

　　与ssh中Host key verification failed问题一样。

　　网上很多的解决方案是：vi ~/.ssh/known_hosts 删除与想要连接的主机相关的行;或者直接删除known_hosts这个文件。 当然这个方案也是可行的，但并非解决问题的根本办法，因为继续使用，今后还会出现这样的情况，还得再删除。

　　下面简单讲一下这个问题的原理和比较长久的解决方案。

　　用OpenSSH的人都知ssh会把你每个你访问过计算机的公钥(public key)都记录在~/.ssh/known_hosts。当下次访问相同计算机时，OpenSSH会核对公钥。如果公钥不同，OpenSSH会发出警告，避免你受到DNS Hijack之类的攻击。

　　SSH对主机的public_key的检查等级是根据StrictHostKeyChecking变量来配置的。默认情况下，StrictHostKeyChecking=ask。简单所下它的三种配置值：

　　1、StrictHostKeyChecking=no

　　#最不安全的级别，当然也没有那么多烦人的提示了，相对安全的内网测试时建议使用。如果连接server的key在本地不存在，那么就自动添加到文件中(默认是known_hosts)，并且给出一个警告。

　　2、StrictHostKeyChecking=ask #默认的级别，就是出现刚才的提示了。如果连接和key不匹配，给出提示，并拒绝登录。

　　3、StrictHostKeyChecking=yes #最安全的级别，如果连接与key不匹配，就拒绝连接，不会提示详细信息。

　　对于我来说，在内网的进行的一些测试，为了方便，选择最低的安全级别。

      在.ssh/config(或者/etc/ssh/ssh_config)中配置：

　　StrictHostKeyChecking no

　　UserKnownHostsFile /dev/null

　　修改好配置后，重新启动sshd服务即可，命令为：/etc/init.d/sshd restart (或 service sshd restart

　　万变云，你先进的网站管理系统选择，覆盖200+城市IP，无论是虚拟主机、VPS云服务器、云主机都能为你提供良好的租用体验。