解決ssh-copy-id時Host key verification failed的錯誤
如果因為某種原因（服務器系統重裝，服務器間IP地址交換，DHCP，虛擬機重建，中間人劫持），這裏筆者是因為虛擬機重建的緣故，該IP地址的公鑰改變了，當使用 SSH 連接的時候會出現
然後筆者把.ssh/knowns_hosts和.ssh/authorized_keys刪除了，重新ssh-copy-id把公鑰復制給其他公鑰試了一下，結果
首先看下正常的步驟：SSH 連接遠程主機時，會檢查主機的公鑰。如果是第一次該主機，會顯示該主機的公鑰摘要，提示用戶是否信任該主機
The authenticity of host ‘192.168.164.23 (192.168.164.23)‘ can‘t be established.
Are you sure you want to continue connecting (yes/no)?
SSH對主機的public_key的檢查等級是根據StrictHostKeyChecking變量來配置的。默認情況下，StrictHostKeyChecking=ask。簡單所下它的三種配置值：
1.StrictHostKeyChecking=no
#最不安全的級別，當然也沒有那麽多煩人的提示了，相對安全的內網測試時建議使用。如果連接server的key在本地不存在，那麽就自動添加到文件中（默認是known_hosts），並且給出一個警告。
3.StrictHostKeyChecking=yes #最安全的級別，如果連接與key不匹配，就拒絕連接，不會提示詳細信息。
對於我來說，在內網的進行的一些測試，為了方便，選擇最低的安全級別。在.ssh/config（或者/etc/ssh/ssh_config）中配置：
Host *
StrictHostKeyChecking no
Q:如何防止遠程主機公鑰改變導致 SSH 連接失敗？
A:當確認中間人劫持×××風險比較小的情況下，才可以使用下面的方法，禁用 SSH 遠程主機的公鑰檢查。 SSH 客戶端提供一個 UserKnownHostsFile 配置，允許指定不同的 known_hosts 文件。那麽將 known_hosts 指向不同的文件，不就不會造成公鑰沖突導致的中斷了麽？
Host *
UserKnownHostsFile /dev/null
綜上
在.ssh/config（或者/etc/ssh/ssh_config）中配置
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
或者將兩個命令結合起來使用
ssh-copy-id -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /root/.ssh/id_rsa.pub root@hdp23
同樣第一次連接需要
ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@hdp23
以後就可以直接使用ssh hdp23連接了
然後scp復制文件也是同樣的道理
scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r /var/tmp/performance/moo.dat root@hdp23:/var/tmp/
如有不當之處，請各位大神指教。
解決ssh-copy-id時Host key verification failed的錯誤