在 SSH 客戶端 OpenSSH 和 PuTTY 中 ( 在 PuTTY 和 在OpenSSH中），導致連接協商演算法中資訊的外洩。 此漏洞允許攻擊者攔截用戶端流量（例如，當使用者透過攻擊者控制的無線存取點進行連接時），以偵測在用戶端尚未快取主機金鑰時最初將用戶端連接到主機的嘗試。
知道用戶端是第一次嘗試連線且還沒有主機金鑰，攻擊者可以透過自身廣播連線 (MITM) 並向用戶端提供其主機金鑰，SSH 用戶端將考慮使用該主機金鑰如果目標主機未驗證金鑰指紋，則為目標主機的金鑰。 因此，攻擊者可以在不引起使用者懷疑的情況下組織 MITM，並忽略用戶端已快取主機金鑰的會話，嘗試取代將導致有關主機金鑰變更的警告。 該攻擊是基於用戶的粗心，他們在第一次連接時沒有手動檢查主機密鑰的指紋。 檢查密鑰指紋的人可以免受此類攻擊。
作為決定第一次連線嘗試的標誌，使用了列出支援的主機金鑰演算法的順序的變更。 如果發生第一次連接，用戶端會傳輸預設演算法列表，如果主機金鑰已在快取中，則將關聯的演算法放在第一位（演算法按優先順序排序）。
該問題出現在 OpenSSH 版本 5.7 至 8.3 和 PuTTY 0.68 至 0.73 中。 問題 在問題 透過新增一個選項來停用主機金鑰處理演算法清單的動態構建，有利於以恆定順序列出演算法。
OpenSSH 專案不打算更改 SSH 用戶端的行為，因為如果您一開始就沒有指定現有金鑰的演算法，則會嘗試使用與快取金鑰不對應的演算法，並且將顯示有關未知金鑰的警告。 那些。 出現一個選擇 - 要么資訊洩漏（OpenSSH 和 PuTTY），要么如果保存的密鑰與預設清單中的第一個演算法不對應，則發出有關更改密鑰的警告（Dropbear SSH）。
為了提供安全性，OpenSSH 提供了使用 DNSSEC 中的 SSHFP 項目和主機憑證 (PKI) 進行主機金鑰驗證的替代方法。 您也可以透過 HostKeyAlgorithms 選項停用主機金鑰演算法的自適應選擇，並使用 UpdateHostKeys 選項可讓用戶端在驗證後取得其他主機金鑰。
來源： opennet.ru