如果用戶端產生對稱會話金鑰，然後使用伺服器的公鑰加密並將其傳送到伺服器，則只有伺服器可以使用其私鑰解密加密的會話金鑰，反之亦然。
答案1
這種密鑰交換方法確實存在——事實上，很長一段時間以來，這就是基本的金鑰在 SSL/TLS 中交換的方式，而類似的方案是 SSHv1 中唯一可用的交換方法（現已過時）。
然而，兩個系統都已遷移從與 DH 的基於加密的金鑰交換。
你描述的機制有一個主要問題：如果伺服器的私鑰被盜，它可以用來解密每一個連接之前使用該密鑰對製作的或將要製作的。 （換句話說，它缺乏前向保密.)
考慮到 HTTPS 憑證過去頒發的有效期限為 5 年甚至 10 年，而 SSH 則直接頒發依靠如果主機密鑰一旦建立就不會改變，這可能是一個相當大的風險。 （例如，如果同一攻擊者一直在監視資料中心上的網路流量...或者如果您居住在參與 PRISM 或 XKeyscore 等監視計劃的國家/地區。）
（SSHv1 試圖透過產生用於金鑰交換目的的臨時RSA 金鑰來緩解此問題，但這完全否定了使用「已知」伺服器金鑰來加密內容的優勢。並且由於RSA 金鑰產生需要大量處理，因此每隔幾個小時執行一次，且臨時金鑰僅限於 768 位元。
另一個問題是需要加密能力限制您對關鍵演算法的選擇。如果我理解正確的話，非對稱數位簽章（用於驗證 DH 金鑰交換）比非對稱加密更容易實現，即使對於那些演算法可以兩者都做——但並非所有人都能做到。
例如，EC金鑰不能直接用於加密，只能用於簽章和金鑰交換。有一些方案使用 EC 金鑰（例如 ECMQV）實現加密，但它們實際上是基於ECDH金鑰交換。那就直接用DH吧。