SSHと中間者
次のシナリオを想定し、どこか間違っている場合は修正してください。
クライアントがあり、クライアントが接続するSSHサーバーがあります。クライアントの着信および発信トラフィックを傍受できる中間者（MIM）もあります。
ここで、クライアントが初めてSSHサーバーに接続し、サーバーの公開鍵情報がknown_hostsファイルにまだ含まれていないと仮定します。サーバーはその公開鍵をクライアントに送信し、クライアントはknown_hostsファイルをチェックし、そこでサーバーの公開鍵を見つけられないので、サーバーはその身元をクライアントに証明する必要があります。 IDは（サーバーの秘密キーを使用して）正常に証明されていますが、その後、クライアントがサーバーの公開キーをknown_hostsに格納しないと想定します（私が知る限り、known_hostsに格納する必要はありません）。
次回クライアントがSSHサーバーに接続するときに、中間者（MIM）がクライアントの接続要求を傍受し、実際のSSHサーバーに代わって独自の公開鍵をクライアントに送信します。クライアントはMIMの公開鍵を受信し、known_hostsファイルを検査しますが、そのファイルで受信した公開鍵を見つけられないため、「サーバー」（MIM）はIDを再度証明する必要があります。 MIMの公開キーは対応する秘密キーに関連付けられているため、MIMはそのIDをクライアントに正常に証明します。
その方法でセキュリティを危険にさらすことは可能ですか？どこか間違っていたら訂正してください。
サーバードメインの証明書で問題を解決できるとのことで、ホスト証明書の目的を理解したいと思います。証明書が通常の公開鍵と同じようにknown_hostsファイルに入れられることを読みました。しかし、ドメイン内のすべてのサーバーで同じ公開鍵を使用し、その公開鍵をクライアントのknown_hostsファイルに単に入れる場合、証明書を使用する意味は何ですか？明らかに、known_hostsに公開鍵がない場合でも、上記で説明した攻撃は依然として可能であり、サーバーが証明書を使用しているかどうかは関係ありません。
サーバーの身元は、提示された公開鍵をサーバーが所有していることを証明するサーバーによって証明されていると想定しているようです。しかし、これはクライアントの観点からサーバーの身元を証明するものではありません。
サーバーのIDを検証する際の重要な部分は、クライアントがサーバーの公開キーを期待されるものと照合して検証することです。そのため、最初の接続時またはキーが変更された場合に、フィンガープリントが検証のためにクライアントに提示されます。つまり、フィンガープリントまたは公開鍵は、事前に、つまり鍵の検証前に、クライアントに認識されている必要があります。あなたが説明するのは、代わりに希望でユーザーに提示されたすべての鍵を盲目的に信頼することですが、それが正しいものであることは確実ではありません（ TOFU-初回使用時の信頼 ）。
誰かがサーバードメイン証明書が問題を解決できると私に言った
SSHの証明書は [〜＃〜] tls [〜＃〜] （したがって [〜＃〜] https [〜＃〜] の証明書と同様の役割を果たします。内部には公開鍵があり、クライアントが信頼する認証局によって発行および署名されます。証明書ベースの認証の場合、サーバーは公開鍵と発行者の署名を含む証明書を提示します。発行者の署名を使用して、証明書がローカルで信頼された機関によって発行され、証明書の公開鍵が実際に予期されるサーバーの鍵であることを検証できます。その後、公開鍵は通常の鍵ベースの認証と同じように使用されます。つまり、サーバーは、公開鍵の秘密鍵を所有していることを示す必要があります。
したがって、証明書を使用すると、クライアントはすべてのサーバーキーを事前に知る必要がありません。代わりに、特定の機関がサーバーの公開キーを含む正しい証明書を発行して署名することを信頼するだけで十分です。これにより、すべてが少数のエンティティーによって管理されている多くの異なるシステムを扱う場合、よりスケーラブルになります。
SSHで証明書を使用する方法については、例 SSH CAを作成してUbuntuでホストとクライアントを検証する方法 を参照してください。