手動ハッシュ検証はDHMITM攻撃から防御できますか？
DHキー交換がMITM攻撃に対してどのように脆弱であるかを理解しています。
アリスがボブg、pと彼女の公開鍵を送信するとき、値g、pと公開鍵がすべて連結されたハッシュである値Hも送信した場合、彼女とボブは電話をかけて、 Hは両方とも同じ値であり、g、p、および公開鍵の値がそれぞれ同じであると確信できますか？
DH鍵交換の主なポイントは、匿名の当事者が鍵を交換できるようにすることであり、このような手動の手順は、DH鍵交換のポイントを完全に見逃していることを理解しています。
それでも、これは機能しますか？
アリスは、ネットワークを介してハッシュ値を送信する必要はありません。代わりに、ボブは受け取った値に基づいて自分の側でハッシュ値を再計算し、ハッシュ値を信頼できるソース（電話）と比較する必要があります。
これは機能します。 2つのステップでそれを検討するかどうかは簡単にわかります。
Diffie-Hellmanが存在する場合、 Man-in-the-Middle攻撃 では、攻撃者はAliceまたはBobからの公開鍵の代わりに自分のDH公開鍵を配置する必要があります（MitMは二重のなりすましです） 、したがって、攻撃者は置換を2回行う必要があります）。ボブが受け取ったものが、実際にアリスがそのような置換を検出するために送信したものであることを「確認」するだけで十分です。ボブはアリスに電話をかけ、電話回線を介して、受け取ったDH公開鍵（DHグループパラメーターpおよびg、およびアリスからの実際のDH公開鍵gamodp）。
3つの大きな整数（1500を超える16進文字）をスペルアウトする代わりに、アリスとボブは値のハッシュを使用できます。ハッシュ関数がsecond-preimage耐性である限り、ハッシュ値の検証は完全な公開鍵の検証と同じくらい優れています。
このメソッドは正確に[〜＃〜] ssh [〜＃〜] で何が起こるかです。これまで知られていなかったSSHサーバーに初めて接続すると、次のようになります。
The authenticity of Host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?
この時点で、目的のサーバーのsysadminに電話して、ハッシュ値を確認する（または、コンテキストに応じて、他の信頼できるソースと照合する）ことになっています。これはまさにあなたが提案するものです。次に、SSHクライアントはサーバーからの公開鍵を記録するため、以降の接続でそのような質問は必要ありません。