最近开始工作，也遇到了一些技术上的问题，做一些日常记录，以便以后的整理。

解决办法

SSH在连接远程服务器时，最开始使用的是本地cmd，并且执行了三次都报错，但换成mobaXterm就没问题，于是我百度搜了一下，大部分的文章说的是：这是一种安全机制，一般第一次会出现The authenticity of host ' ' can't be established. ECDSA key fingerprint is SHA256:.

本地主机key发生变化，所以SSH每次都会出现这个提示，输入yes也可以解决。

如果长久的想解决问题，可以采用以下方法：
1、使用ssh连接远程主机时加上“-o StrictHostKeyChecking=no”的选项，去掉对主机的验证检查。

ssh -o StrictHostKeyChecking=no 192.168.xxx.xxx

2、当然你也可以直接改配置文件信息，这样彻底去掉验证。

修改/etc/ssh/ssh_config文件（或$HOME/.ssh/config）中的配置，添加如下两行配置：

StrictHostKeyChecking no
UserKnownHostsFile /dev/null
注：不过采用第二种方法，容易造成潜在的危险。

原理

主机公钥确认 StrictHostKeyChecking

StrictHostKeyChecking=no 最不安全的级别，当然也没有那么多烦人的提示了，相对安全的内网测试时建议使用。

如果连接server的key在本地不存在，那么就自动添加到文件中（默认是known_hosts），并且给出一个警告。

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

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

SSH 公钥检查是一个重要的安全机制，可以防范中间人劫持等黑客攻击。但是在特定情况下，严格的 SSH 公钥检查会破坏一些依赖 SSH 协议的自动化任务，就需要一种手段能够绕过 SSH 的公钥检查。

导致Key变化的原因

服务器系统重装

服务器间IP地址交换

DHCP

虚拟机重建

中间人劫持

未解决的点

当时连接的时候，使用的是Windows自带的cmd，然后出现的报错，但换成mobaXterm就没问题，我也不太知道Windows底层的逻辑，但我猜测，估计是cmd需要再次重新打开才能识别到第一次添加的key。