科技 · 實用指南
SSH 顯示「kex_exchange_identification: Connection closed」？先對齊預先驗證邊界
這條訊息早於一般登入失敗。先固定實際路由、保存用戶端停止點，並以同一時間戳對齊入口與 sshd 日誌，只修改真正關閉連線的元件。
kex_exchange_identification: Connection closed by remote host 不能證明私鑰錯誤。它表示 TCP 到達某個對端，但連線在 SSH 識別交換或早期金鑰交換附近結束，尚不能當作一般使用者驗證失敗。
把事件整理成三個觀察點的時間線：用戶端、網路入口與 SSH 守護程序。同一訊息可能來自錯誤連接埠、代理或防火牆、sshd 啟動限制、來源懲罰或明確拒絕。
固定實際端點與一次失敗時間
記錄主機、解析位址、連接埠、來源位址、ProxyJump 或 ProxyCommand、VPN 狀態與呼叫者，保存一個 UTC 時間戳及完整 ssh -vvv。
不要假定熟悉的主機名一定到達預期 sshd；負載平衡、NAT、面板連接埠、跳板或舊 DNS 都可能接受 TCP 後在驗證前關閉。
標記用戶端真正到達的最後協定邊界
在用戶端記錄找伺服器識別行與第一個 SSH 金鑰交換訊息。若沒有 SSH banner，先查監聽器與入口路由。
RFC 4253 要求連線建立後雙方傳送識別字串；此處關閉是傳輸或預先驗證現象，不是 authorized_keys 拒絕證據。
對齊入口決策與 sshd 預先驗證日誌
以相同時間戳讀取防火牆、NAT、負載平衡、代理與主機安全日誌，再讀 sshd journal，確認哪個後端收到了連線。
讀取包含來源 Match 結果的生效 sshd 值；優先使用有限的暫時日誌，避免長期開啟全域除錯並保護使用者資料。
改限制或金鑰前先分類關閉原因
區分錯誤目標、無監聽器、MaxStartups、每來源限制、來源懲罰、RefuseConnection、LoginGraceTime 與外部政策工具。由證據決定分支。
不要只因論壇提到 MaxStartups 就提高它；更高上限可能增加負載，卻無法修正錯誤路由、攻擊流量或來源政策。
只做一項最小修復並驗證前進
只修正被證明的錯配：正確路由、具體代理或後端、精確 Match 規則、合規的監控豁免或已證實的容量限制。
從已知來源重試一次，確認收到正確 SSH 識別、sshd 記錄同一嘗試並進入預期驗證，再執行一個真實命令且不全面停用保護。
