サーバーのフィンガープリントがチェックされておらず、公開鍵認証が使用され、そのサービスに機密性が必要ない場合、SSHはMiTMに対して安全ですか？
初めてサーバーに接続するとき、sshは通常、ユーザーにサーバーの指紋を確認してから情報をキャッシュするように要求します。 これは、MiTMを防ぐために必要です。
ユーザーが指紋を手動で確認する必要があるのはSSHの設計上の欠陥ですか？次のユースケースを意味します。
サーバーがあります。クライアントがいます。サーバーは、認証されたユーザーにパーソナライズされたサービスを提供します。したがって、ユーザーの資格情報を適切にチェックするのはサーバーの責任です。
サーバーはその指紋を知っています。クライアント（sshではなく、gitのGUIクライアントなどのsshに基づいて構築されたアプリ）がフィンガープリントをチェックするために配線を解除していると仮定しましょう。実装されます。
認証プロトコルは、クライアントが署名することです サーバーが提供するチャレンジ、サーバーはそれを検証し、アクセスを許可します。 悪意のあるサーバーは、MiTMを実行してユーザーの応答を元のサーバーにプロキシすることにより、ユーザーを正規のサーバーに偽装する可能性があります。
これを修正する方法は、チャレンジだけでなくサーバーのフィンガープリントにも署名することです。 （右の画像については、承認された回答を参照してください）その後、サーバーはMiTMサーバー側を検出できます。ただし、悪意のあるサーバーがユーザーになりすまされるのを防ぐことはできません。
つまり、設計上の欠陥ではありません。あなたはデザインについて誤解しました。
認証プロトコルは、クライアントがサーバーから提供されたチャレンジに署名し、サーバーがそれを検証してからアクセスを許可するというものです。
クライアントは、サーバーが提供するチャレンジに署名しません。代わりに、クライアントは RFC 4252セクション7 で定義された構造に署名します。これには、主要なコンポーネントとしてセッション識別子が含まれます。このセッションID自体は、 RFC 4253セクション7.2 で説明されているキー交換の結果です。
...悪意のあるサーバーは、MiTMを実行し、ユーザーの応答を元のサーバーにプロキシすることにより、ユーザーを正規のサーバーに偽装できます。
MITMはクライアントの秘密鍵にアクセスできないため、この鍵で新しい署名を作成できません。したがって、サーバーがクライアントによる元の署名を受け入れるようにする方法を見つける必要があります。また、署名はセッション識別子に依存するため、MITMはクライアントとMITMの間、および同じセッション識別子を持つ両方のMITMとサーバーの間のSSH接続を確立する必要があります。
ただし、Diffie Hellman鍵交換では、鍵交換の結果は、サーバーにとって未知のクライアントデータと、クライアントにとって未知のサーバーデータの両方に依存します。 MITMは各接続の片側のみを制御できるため、鍵交換の結果を制御できず、セッション識別子を制御できません。
したがって、あなたが説明する攻撃は機能しません。サーバーがクライアントを適切に認証している限り、MITMは単にクライアントを偽装することはできません。署名が壊れている（セッションIDと一致しない）ために認証が失敗するか、公開鍵がサーバーが予期するものではないために失敗します（MITMが独自のクライアント鍵を作成した場合）。
ユーザーが指紋を手動で確認する必要があるのはSSHの設計上の欠陥ですか？
これには長所と短所があります（驚き！）。
WebサイトはHTTPSに「信頼できる」サードパーティを使用しています。私たちは皆、あなたとあなたの銀行との間の接続を検証するために、Staat Der Nederlanden、Chunghwa、Atos、および中国金融認証局を信頼していますか？それはまさに彼らがやっていることであり、これは過去にうまくいかないことが知られているからです。しかし、それは私たちが得た最高のものです。私たちの母親が銀行に電話をかけて指紋を要求することを期待することはできないため、これらの半信頼できる認証局を使用する必要があります。
SSHの場合、これは主にシステム管理者または他のパワーユーザーによって使用されるため、指紋をチェックするか、少なくともそれが何であるかを理解することを期待する方が合理的です。セキュリティを意識した管理者は、必要に応じてそれを確認できます（たとえば、私はITセキュリティコンサルタントとして働いており、接続する前に指紋を確認しています）。それ以外の場合は、少なくとも Sjoerdがすでに言及されているように、最初の使用時に信頼されます なので、気付かずに変更することはできません。攻撃は最初から存在している必要があり、気付かれないように無期限に継続する必要があります。
悪意のあるサーバーがMiTMを実行してユーザーの応答を元のサーバーにプロキシすることにより、ユーザーを正規のサーバーに偽装する可能性があります。
他のスキームと同じですよね？いつでもMitMしてトラフィックをプロキシできます。 sshの場合、最初に間違ったフィンガープリントを取得するか、後続の接続でファットアラートを取得します。httpsの場合、証明書の警告を取得します。
これを修正する方法は、チャレンジだけでなくサーバーのフィンガープリントにも署名することです。その後、サーバーはMiTMサーバー側を検出できます。
これを次のように考えます。
A：こんにちは、bob.example.comのSSHサーバーです。
B：あいさつ、見知らぬ人。これが私の公開鍵です：abcdef
M：メッセージをインターセプトし、abcdefを123456に変更します
A：こんにちは、公開鍵123456のサーバーbobです。パスワードはbz8iuqw45のアリスです。
M：メッセージを傍受し、123456をabcdefに変更します
B：こんにちは、アリス！ログインに成功しました！
攻撃者は独自の公開鍵を使用するため、トラフィックを復号化できます。データを転送するときに、指紋を置き換えることができます。相互認証を行う必要があります。クライアントは、サーバーによって既に信頼されている公開鍵を提供します。そうして初めて、サーバーは、クライアントが正しいキーを使用していて、中間者ではないことを確実に認識します。しかし、今度は問題を逆転させました。サーバーは、サーバーのユーザーではなく（ユーザーの公開鍵の）正しいフィンガープリントを知っている必要があります。鍵の配布という問題は残っています。
クライアントが指紋をチェックするためにアンウィリングしていると仮定しましょう。これを行うには、何らかの方法で本当の指紋を取得する必要があるためです。
接続時に指紋を信頼せずに指紋を取得することは不可能であることを意味しますか？ ssh経由で接続する前に、サーバーをインストールするときに実際の指紋をつかむことができるからです。
一部のクライアントが指紋をまったくチェックしていないようです
それはクライアントの脆弱性です。フィンガープリントをチェックしたいが、クライアントがそれをサポートしていない場合、それらのクライアントを使用することはできません。私が言ったように、このデフォルトのスキームには長所と短所があるので、「sshプロトコルの作成者がすべて間違っていたため、クライアントがセキュリティを無視している」と言うのは少し簡単です。変更したい場合は、 SSHはpaj28で述べたように認証局をサポートしています です。