根據公鑰對使用者進行身份驗證時 SSH 伺服器密鑰洩露的影響
星期五，我們與我的一位同事就 SSH 伺服器密鑰洩露的影響發生了分歧
問題是這樣表述的：
提供 SSH 伺服器私鑰和中間人位置時，黑客可以做什麼，特別是當客戶端使用公鑰進行身份驗證時（伺服器配置不允許基於密碼的身份驗證）
20分鐘後，我們可以就以下事實達成一致：
流解密（例如，SSH 是否使用使用兩個公鑰加密的臨時密鑰？）
流篡改（與 HMAC 密鑰相同的問題）
- 身份盜竊：（能夠篡改根連接並用伺服器中的黑客替換使用者的公鑰；使用者的私鑰在他的電腦中是安全的……是嗎？）
- 身份替換：能夠將身份驗證對話框劫持到受感染的伺服器，並與其他未受攻擊的伺服器身份驗證對話框實時重播（==> 黑客攻擊伺服器 A，劫持客戶端 C 與伺服器 A 的連接並將海盜連接為 C到未受損的伺服器 B)
（任何其他想法的佔位符:)）
任何人都可以幫助我們解決這些問題嗎？
答案請參閱下面的@PauloEbermann 答案或本文http://www.gremwell.com/ssh-mitm-public-key-authentication
在SSH 的常見配置中，會話密鑰（和會話 ID）將使用Diffie-Hellman 密鑰交換進行協商，然後由伺服器進行身份驗證，使用其私鑰對所有交換的數據進行簽名（然後由客戶端）。
客戶端的公鑰認證在此之後發生，實際連接已經在執行，並且不影響加密（和 MAC）。但是公鑰認證是對多個值的簽名，包括會話標識符。
因此，實際上，如果攻擊者擁有伺服器的密鑰，她可以假裝是伺服器（對客戶端）。她必須接受公鑰登錄，並向客戶展示一些 shell 或類似的東西。
對攻擊者不起作用的是同時（作為客戶端）連接到伺服器，並使用客戶端的公鑰認證向伺服器認證自己，因為簽名中包含會話 ID，會話 ID 將是不同的 Diffie-Hellman 密鑰交換不同。
此外，似乎不可能以一種仍然知道創建的密鑰的方式操縱 Diffie-Hellman 密鑰交換，並且它們（以及會話 ID）對於兩個連接都是相同的。
使用RSA 密鑰交換（客戶端簡單地使用臨時伺服器密鑰對一些隨機數據進行 RSA 加密並將其發送到伺服器，雙方都從這個共享密鑰中獲取所有內容（以及交換的其他內容，如公共密鑰，提供的密鑰交換方法等），MiTM 攻擊（知道伺服器的臨時私鑰）是可行的 - 只需解密此消息，然後您就知道用於加密和身份驗證的密鑰（以及消息 ID） ，並且可以閱讀和修改所有進一步的消息。
如果她只知道伺服器的長期私鑰，事情就不那麼簡單了：雖然她可以用她自己的密鑰替換臨時伺服器密鑰，但這會導致不同的會話 ID（和會話密鑰），因此公共-客戶端的密鑰身份驗證將不再對她起作用。