🔑 設備更換但 IP 不變？SSH Host Key Verification Failed 的正確處理方式
機房裡把一台設備換掉、但管理 IP 沿用舊的，是很常見的操作。這時候用同一台管理電腦 SSH 上去，十之八九會撞上 Host key verification failed。這篇整理這個錯誤的成因、跟「第一次連線」那種提示的差異，以及正確的處理方式。
1️⃣ 兩種長得很像、但意義不同的提示
SSH 對「host key 的狀態」其實分兩種情境判斷，錯誤訊息完全不同，混在一起看容易誤判。
情境 A：第一次連線,SSH 資料庫裡完全沒有這個 IP 的紀錄
The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ED25519 key fingerprint is: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
這是正常流程,SSH 會停下來問你「要不要信任這把新看到的 key」,輸入完整的 yes(不是按 Enter、也不是打 y)就會繼續連線,並把這把 key 寫進 ~/.ssh/known_hosts。
情境 B：以前連過,這次收到的 key 跟記錄的不一樣
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:32
Host key for 192.168.1.10 has changed and you have requested strict checking.
Host key verification failed.這種情況 SSH 不會給 yes/no 選項,直接擋下連線。這是刻意設計的行為:「同一個 IP 之前連過、現在 key 卻不一樣」是 SSH 最重視的風險訊號之一,因為理論上這正是中間人攻擊（MITM）的典型特徵——攻擊者在你跟真正目的地之間插入自己的機器,用自己的 key 冒充對方。SSH 沒辦法自動分辨「這是真的攻擊」還是「設備真的換了」,所以一律先擋下來,把判斷權交還給人。
2️⃣ 為什麼設備沒換,key 卻可能不一樣;為什麼設備換了,key 一定不一樣
SSH host key 是設備第一次啟動 SSH 服務時自動產生的一組金鑰對,跟設備的「身分」綁在一起,不是跟 IP 綁在一起。幾種常見情境:
- 換了一台實體設備,IP 沿用舊的:新設備的 host key 一定跟舊設備不同,這是預期中的正常變化。
- 同一台設備做了原廠重置（factory reset）或組態清空重建:許多系統在這種情況下會重新產生一組新的 host key,即使實體設備沒換,key 也會變。
- 金鑰演算法被管理者手動更換(例如從 ECDSA 換成 ED25519):即使設備沒換、也沒重置,只是換了金鑰型別,key 內容也會不同。
反過來說,如果你確定設備完全沒動過、也沒人去改過 SSH 設定,卻收到「host key changed」的警告,這時候更該提高警覺,先透過其他管道(電話確認、直接到現場看設備狀態)排除真的被中間人攻擊的可能性,不要急著清掉警告就繼續連線。
3️⃣ 正確處理方式:ssh-keygen -R
確認是「設備確實更換過」之後,正確做法是移除 known_hosts 裡舊的那筆紀錄,而不是手動去檔案裡找那一行刪除(手動編輯容易刪錯行或漏掉重複紀錄)。
ssh-keygen -R 192.168.1.10這行指令會找出 known_hosts 裡所有跟這個 IP(或主機名稱)對應的紀錄並移除,同時保留一份備份:
# Host 192.168.1.10 found: line 31
# Host 192.168.1.10 found: line 32
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old💡 這裡如果看到「found」不只一行(像上面範例的 line 31 和 32),代表這個 IP 過去曾經被記錄過不只一次、且是不同的 key。這通常代表這個 IP 過去至少經歷過一次類似的變動(設備換過、或金鑰型別換過),值得回頭確認一下歷史紀錄,而不是單純當作這次的偶發狀況。
清除舊紀錄之後,再次連線就會回到情境 A(第一次連線)的正常流程:
ssh root@192.168.1.10
The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ED25519 key fingerprint is: SHA256:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.10' (ED25519) to the list of known hosts.
(root@192.168.1.10) Password:
輸入完整的 yes,新的 key 就會被寫入 known_hosts,之後同一台管理電腦連這個 IP 就不會再跳警告,除非 key 又再次改變。
4️⃣ 一個容易被忽略的線索:「This host key is known by the following other names」
重新連線時,有時候會多看到這一行:
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:17: 192.168.0.99這代表這次收到的這把 key,你的管理電腦「之前也在另一個 IP 上見過」。如果那個舊 IP 對應的正是你認識的某台設備,這其實是一個很有用的佐證:代表現在這個新 IP 上的設備,跟那台舊設備是同一台(或至少共用同一把 host key,例如同一份出廠映像檔或同一次組態還原)。這種交叉比對,在排查「這台設備到底是不是我認識的那台」時很實用,不要因為只是一行附加訊息就忽略掉。
5️⃣ 常見誤區
| 誤區 | 問題 | 正確做法 |
|---|---|---|
| 看到 warning 就直接刪 known_hosts 整個檔案 | 連同其他所有設備的信任紀錄一起清掉,之後每台都要重新確認一次,而且失去了「異常變動」的偵測能力 | 只針對特定 IP 用 ssh-keygen -R |
用 StrictHostKeyChecking=no 一勞永逸關掉檢查 |
等於放棄 SSH 對 MITM 攻擊的偵測能力,長期使用風險很高 | 只在明確知道是暫時測試環境時短期使用,正式環境不建議關閉 |
| 看到「host key changed」直接當作設備正常更換,沒有進一步確認 | 如果實際上是中間人攻擊,這麼做等於主動忽略警告 | 先透過其他管道確認設備狀態,確定是預期中的變動才清除紀錄 |
| 連線提示要求輸入 yes 時只按 Enter 或打 y | SSH 需要完整輸入 yes,其他輸入會被視為拒絕,導致 Host key verification failed |
務必輸入完整的 yes |
📚 延伸閱讀（站內相關文章）
- Linux SSH 安全強化：MFA 與 Fail2ban 實戰指南 – SSH 存取安全的進一步強化做法。
- Linux SSH 安全強化：金鑰驗證與 Fail2ban – 改用金鑰驗證後,host key 驗證機制同樣適用。
- Juniper 帳號與密碼安全強化：RADIUS/TACACS+ 整合 – 設備端帳號治理,搭配本篇管理端的連線驗證機制。
- Juniper SRX 8-Port 測試環境設定範例 – 測試機組態範例,重建或重置設備時常見的情境來源。
✅ 結論與行動建議
Host key verification failed 不是故障,是 SSH 刻意設計的保護機制,用來偵測「同一個位址、身分卻變了」這種可能的攻擊情境。設備確實更換或重置後,用 ssh-keygen -R <IP> 移除舊紀錄是正確且安全的做法;但看到這個警告的第一反應不該是「趕快清掉繼續連」,而是先確認變動的原因是不是預期中的——尤其是自己也不確定設備最近有沒有被動過的情況下,多花一分鐘確認,比事後排查資安事件划算得多。
沒有留言: