1つのワイヤレスネットワークでのSSHホストIDの変更
SSHを介して、Ubuntuシステムからデフォルトのポート22でリモートサーバーに定期的に接続します。サーバーをexample.org。このサーバーが正しく構成されていることを確認しており、次の問題が私のOSに依存せず、再インストールしても問題が発生しないことを確認しました。
サーバーに接続すると、特定のWifiアクセスポイントが1つあります（ssh example.org）、私はこれを得ます：
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE Host IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a Host key has just been changed.
The fingerprint for the ED25519 key sent by the remote Host is
SHA256:[REDACTED].
Please contact your system administrator.
Add correct Host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:3
remove with:
ssh-keygen -f "/home/user/.ssh/known_hosts" -R "serv.org"
ED25519 Host key for serv.org has changed and you have requested strict checking.
Host key verification failed.
問題のあるアクセスポイントは学術機関に属しており、商用ISPネットワークよりもロックダウンされているようです（たとえば、トレントをダウンロードできません）。別のネットワークに戻った場合（たとえば、自分の電話をアクセスポイントとして使用している場合）、再度接続できます。
Wiresharkによると：
- DNSクエリ（
8.8.8.8） ためにexample.orgは、問題のあるアクセスポイントであっても、同じIPアドレスを返します。 - SSHキー交換は通常どおり行われるようですが、問題のあるAP経由で接続しているときに、「ECDHキー交換応答」でサーバーから送信されたキーのフィンガープリントは確かに異なります。
このネットワークが何をしているのか分かりません。ポート22をブロックすることは1つのことですが、ここではサーバーに到達し、応答として間違ったキーを取得するようです。
このアクセスポイントは、意図的にSSH接続を改ざんしていますか？これにもかかわらずSSHを安全に使用する方法はありますか？使用しないでください。
このシステムのホストキーが変更されているか、誰か/何かがSSH接続をMITMしています。
適切な処置は、説明がない限り、ホストが危険にさらされていると見なすことです（ただし、接続自体ではなく、ホスト自体ではありません）。
そのAPのシステム管理者に連絡して、懸念事項を通知し、これを追跡することをお勧めします。
学術機関なので、おそらくデータ損失防止（DLP）や一般的な監査ログなどのSSHトラフィックを傍受して分析するファイアウォール/セキュリティゲートウェイだと思います。
このようなファイアウォールの例： https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/decryption/decryption-concepts/ssh-proxy.html
Davidgoの答えは正しいです。パスワードではなくpubkey authを使用している限り、このMITMは資格情報の安全性を損なうことはありません。しかし、セッションを介して送信されるあらゆるもののプライバシーと信頼性が損なわれます。 「セッションを介して送信されたあらゆるものの信頼性」には、シェルに送信されたコマンド、またはユーザーが操作しているプロセスや送信された出力が含まれます（おそらく完全にそれで構成されます）。
私はもともと次のことを提案していました危険なほど間違っていますであり、少なくともそれ以上の対策はありません：
簡単な回避策の1つはdouble-sshです。ログインしているホストがポート転送を許可していると仮定し、危害を受けた接続で一度ログインし、pubkey authを使用し、転送を有効にしてローカルポートを
localhost:22に転送します。-L 12345:localhost:22。これで、最初のトンネルを通過する2番目のsshセッションを実行できます。攻撃者がこれを行うことを積極的に予期していない限り、この2番目のセッションは正しいホストフィンガープリントを持ち、それが実際に安全であり、MITMによる傍受の対象ではないことがわかります。
これは、私がそうすることを心がけた正しい方法から単純化して、シェルではなく、純粋に転送用に別のログインアカウントを使用することで、簡潔に書かれました。 d）接続ですが、注意が必要です。また、authorized_keysファイルをセットアップして、初回（MITM'd）ログインに使用するキーを制限し、コマンドを発行できず、接続のみを転送できるようにすることもできます。もしそうなら、そのような設定は安全でなければなりません。