このSSH警告が本物の中間者攻撃ではないことをどのように確認できますか？ 「警告：リモートホストIDが変更されました！」
私はこの種のものに慣れていないので、中間者攻撃を排除したいと思います。
Windows 10 PCからSSH経由でRaspberry Pi 4にLAN内で接続していますが、このメッセージが表示されます。私はシステム管理者なので、確認する必要はありません。
問題を修正する方法について多くの投稿を見つけましたが、修正する前に実際に攻撃を除外（または確認）するために何をすべきかを知りたいです。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 ECDSA key sent by the remote Host is
SHA256:0xgFiU5j9W2WgyurDOgORf+qeFQoHf0YE6G92KnrduY.
Please contact your system administrator.
Add correct Host key in C:\\Users\\JamesAlesi/.ssh/known_hosts to get rid of this message.
Offending RSA key in C:\\Users\\JamesAlesi/.ssh/known_hosts:2
ECDSA Host key for 192.168.1.123 has changed and you have requested strict checking.
Host key verification failed.
一般的に、あなたが取るアプローチは常に同じです：攻撃者がおそらく操作できないチャネルを介してキーのフィンガープリントを検証します。
たとえば、私の古い大学では、コンピューティングセンターのフロントデスクに行き、すべての重要なキーと証明書の指紋のリストが記載されたチラシを入手できました。それがあなたが個人的に知っている友人のサーバーである場合、あなたは彼らに電話してあなたに指紋を読むように彼らに頼むことができます。ホストされている管理対象サーバーの場合、よりセキュリティ重視のホスティングプロバイダーが指紋をメールで送信することを提案している場合があります。
要点は次のとおりです。[〜＃〜] iff [〜＃〜]ネットワーク接続が危険にさらされていると考える理由があり、ネットワークを使用せずにフィンガープリントを取得してみてください。
Raspberry Piには、いくつかの非常にシンプルなオプションがあります。
- コンピュータからネットワークケーブルを直接Raspberry Piに接続するだけです。ブーム：誰かが中間者攻撃を仕掛ける「中間」はもうありません。
- PCからPiのシリアルコンソールに接続し、コンソールに直接ログインします。ブーム：ネットワークさえもうありません。
- USBキーボードとHDMIモニターをPiに接続し、コンソールに直接ログインします。
- SDカード（またはUSBスティックなどのブートメディア）を取り出し、PCにext2ファイルシステムをマウントします（Linuxを実行していない場合は、追加のソフトウェアが必要になるか、Linux LiveCDで起動できます）。 、および
/etc/ssh/ssh_Host_ecdsa_key。
これは、ホストキーを確認する方法に関するより具体的な質問に答えます。さて、より一般的な質問です。
私はこの種のものに慣れていないので、中間者攻撃を排除したいと思います。
LANに中間者攻撃を仕掛けるために、攻撃者はLANインフラストラクチャへの物理的なアクセスを必要とします。そのため、man-in-the-middle攻撃を排除したい場合は、文字通りケーブルをたどって、「man in the middle」、つまり認識できないデバイスを探すことができます。注意が必要ですが、そのようなデバイスは非常に小さく、隠されている可能性があります。
また、ドアの鍵、または家のその他の入口（窓など）に侵入の兆候を探すこともできます。
これで、妥当性分析を実行できます。RaspberryPiで何をしているのかを確認するために、誰かがあなたの家に侵入し、気づかずにLANにデバイスをインストールした可能性が高くなります。または、192.168.1.123が以前に別のデバイスに割り当てられていた（またはPiを更新または再インストールまたは再構成した）可能性が高く、古いキーがまだPCにキャッシュされていましたか？
ただし、WiFiについて話している場合、MitM攻撃は物理的なアクセスを必要としません。したがって、誰かがあなたに気付かれずにそのような攻撃を仕掛けられる可能性がはるかに高くなります。しかし、問題はまだ残っています：攻撃者はあなたとあなたのPiの間の接続をスニッフィングして何を求めていますか？
同様に、LAN上のデバイスが別のネットワーク（WiFi、近隣ネットワーク、インターネット）にも接続されている場合、このデバイスはthatネットワーク。攻撃者にLANへのアクセスを許可します。
上記のコメントで述べたように、侵害されたRaspberry Piは貴重なものですが、有能な攻撃者であれば、ホストキーを変更しない方法で侵害することを知っています。
初めてホストに接続するとき、SSHはその識別情報を保存します。このIDが将来変更されると、このメッセージが表示されます。
これは、たとえば、ターゲットシステムを再インストールした後、接続に使用したのと同じIP /ホスト名を持つ別のシステムに置き換えた後、またはシステムのサーバーSSHキーを再生成した後に発生する可能性があります。これがあなたが最近やったことのように聞こえるなら、それが理由です。
それはあなたの接続を傍受する（そして実際にそれらのIDを送信する）誰かである可能性もありますが、LANではそれはありそうにありません。
通常ログインするマシンからRaspberry Piにログインします。キーに注意してください。指紋が正しいことを確認します。
どこからでもRaspberry Piにログインするための安全な方法を設定したことがない場合、その方法はありません。次回は、マシンをセットアップするときに行います。たとえば、OSを設定するときに、コンソールからキーフィンガープリントの写真を撮ります。
他のPi：や通常の* nixコンピュータなど、sshで接続した他のデバイスがローカルネットワークにありましたか？
DHCPを使用する場合、あるデバイスに割り当てられた（時間制限付き、DHCP「リース」の形式で）IPアドレスは、後で別のデバイスに再利用される可能性があります。 sshを使用して1つのデバイスに接続している場合、sshはそのIPアドレスのホストキーを記憶しています。新しいデバイスに同じIPアドレスが割り当てられ、sshで接続しようとすると、上記のエラーが発生します。
多くのDHCPサーバーは、IPアドレスを要求するデバイスのMAC（イーサネットハードウェアアドレス）に基づいて「準永続的な」アドレスを割り当てようとしますが、完全ではありません-たとえば、DHCPで使用可能な範囲のすべてのIPアドレスがすでに使用されている場合一部は再利用する必要があります。または、ルーター/ホームサーバー/ DHCPに使用するデバイスがリセットまたは交換された場合。
あなたはハッキングされていません。
とにかく、誰もが個人用LAN上のRaspberry Piへの「man-in-the-middle」アクセスを希望するのはなぜですか？
「…攻撃を修正する前に、実際に攻撃を除外（または確認）するために何をすべきかを知りたいのです。」
「man-in-the-middle」がRaspberry Piを介してLAN内であなたを攻撃する可能性はほとんどありません。彼らが何らかの形であなたのLANに違反し、あなたが彼らが侵入できる素敵なWindowsマシンを持っているなら、彼らがこれを行うことの利点は何ですか？
誰かが「中間者」を行う主な理由は、認証情報などのデータをキャプチャして、それらを使いこなすためです。彼らはRaspberry Piの資格情報を取得しましたが、それは何につながりますか？ Raspberry Piがなんらかの理由で金融取引などを行わない限り、私はそれを疑います。
より可能性の高いシナリオは、Raspberry PiにOSを再インストールしたことです。これにより、識別シグネチャが変更され、最終的には対処しているようなシナリオになります。これが通常、このようなIDの不一致が発生する理由です。何かが識別を変えました。
非Raspberry Piの世界では、これは、ハードウェアのアップグレードなどで、システムディスクをあるマシンから別のマシンに交換した場合に発生する可能性があり、VMなどでは、システムのインストール/削除が非常に簡単です。
どういうわけか自分で確認できる方法のリストのようなものを提供することに関しては、正直に言って、常識の評価を過ぎて、私が概説することは実際には不可能です。
ほとんどの場合、特にRaspberry Piのような比較的一時的なデバイスを扱う場合、このメッセージは無害です。おそらく、別のSDカードを挿入したか、OSを再インストールしたか、同じIPを別のデバイスに割り当てたか、新しいホストフィンガープリントをもたらす可能性のある約12のアクションのいずれかです。ただし、ホストの指紋は確認が非常に簡単であるため、「ほとんどの場合」では解決しないことをお勧めします。
他の人がすでに正しく指摘しているように、信頼できるチャネルを介してホストキーのフィンガープリントを確認する必要があります。言い換えると、PiにSSHで接続して以下のコマンドを実行するだけではなく、除外しようとしている同じ（潜在的な）MitM攻撃に対して脆弱であるためです。この場合、PiのHDMI接続、シリアル、またはその他の信頼できる接続を使用して、ホストの指紋を確認することをお勧めします。
ここで、実際に指紋を確認するには、Raspberry Piにシェルが必要です。 ssh-keygen -l（小文字の「L」）を入力し、[Enter]を押します。キーのファイル名の入力を求められます。必要なキーは/etc/sshにある必要があります（推奨されるデフォルトパスにはシステムのホストキーが含まれていない。ここでは無視してください）。 SSHクライアントが接続を報告したのはECDSAキーです。公開鍵（.pub拡張子）と秘密鍵（拡張子なし）のどちらを使用しても同じ結果が得られますが、rootとしてログインしない限り、公開鍵のみを読み取ることができます。 。
ssh-keygen -lの後に正しい秘密鍵のファイル名を入力すると、その鍵のフィンガープリントが出力されます。次のようになります。
pi@raspberrypi:~$ ssh-keygen -l
Enter file in which the key is (/root/.ssh/id_rsa): /etc/ssh/ssh_Host_ecdsa_key.pub
256 SHA256:0xg...[redacted]...rduY. root@pi (ECDSA)
（そのファイル名はRaspberry Piに対して正しい場合と正しくない場合があります。最初にls -l /etc/sshで確認してください。）
次に、システムが出力するフィンガープリントと、以前にsshから取得したフィンガープリントを慎重に比較します。それらが一致する場合、接続が検証され、ローカル~/.ssh/known_hostsを適切に更新できます。それらが一致しない場合は、さらに調査が必要な奇妙なことが起こっています。
修正する前に、実際に攻撃を除外（または確認）するために何をすべきか知りたいです。
この情報を受信するには、100％信頼できるチャネルを使用する必要があります。
最善の方法は、システムに直接ログインすることです。つまり、キーボードとモニターを接続するか、必要に応じてシリアルコンソールを使用します。
ログインしたら、次のいずれかのコマンドを実行します。
ssh-keygen -l -f <( ssh-keyscan 127.0.0.1 )
または：
for k in /etc/ssh/ssh_Host_*_key.pub; do ssh-keygen -l -f "${k}"; done
この意志：
ssh-keyscan-ローカルシステムのSSHサーバーに接続し、ホストキーをリクエストします- 必要に応じて
127.0.0.1をリモートホストと交換することもできます...この操作をリモートで実行するには、リモートが本人であるという絶対的な信頼が必要であり、ユーザーとリモートの間のすべてが信頼できることが必要です。 127.0.0.1を使用すると、ループバックインターフェイス経由で接続がルーティングされ、ローカルシステムと直接通信します。 （トラフィックを再ルーティングする潜在的なiptablesルールを無視）- 攻撃の場合、
localhostを使用すると、実際には別のホストにリダイレクトされる可能性があるため（/etc/hostsを使用）、使用を避けます。
- 必要に応じて
ssh-keygen-提供されたファイル（-l）のキーのフィンガープリント（-f ${file}）を表示しますssh-keyscan 127.0.0.1（オプション1）で使用すると、実際には実行中のデーモンに接続し、他のクライアントと同じようにキーを照会します- ローカルファイルシステムのファイルで使用する（つまり、オプション2）は、少し安全な（より安全な）アプローチと見なすことができますが、それは間違いを考慮していませんまたは、サーバーの構成が不適切で、キーが別の場所にある場合...正しいキーを探す必要があります。
次に、フィンガープリントを取得したら、接続しようとしているリモートシステムから提供されているキー（例ではSHA256:0xgFiU5j9W2WgyurDOgORf+qeFQoHf0YE6G92KnrduY）と慎重に比較します。
指紋が一致しない場合は、攻撃が進行中であることを確認し、あなたが思うシステム。
指紋が一致すれば、すばらしいです！ ssh-keygen -R ${hostname}を使用して問題を解決し、続行します。
ノート：
- システムが侵害されている場合は、ホストキーも侵害されていると考えなければならない可能性があるという標準的な警告...その場合、知る方法がありません。
- ハッシュの衝突が発生し、2つの異なるキーに同じフィンガープリントが表示される可能性があります。その場合、知る方法がありません。
- ネットワークベースのトラフィックは
iptables...を使用して変更またはリダイレクトできます。システムが侵害されていると思われる場合は、そこでも確認することをお勧めします。
100％信頼できる通信チャネルがなければ、これを行うことは不可能です。あなたのケースでは、Piにログインし、キーを直接取得できます。他の状況では、「同僚の言葉を取る」が必要になる場合があります...信頼を置く場所に注意してください。
私はこの種のものに慣れていないので、中間者攻撃を排除したいと思います。
小さなローカルネットワークでは、あなたが思っているシステムと話している可能性がveryです。
リモートIPアドレスがサブネット内にあり、ネットワーク内に不明または疑わしいデバイスが他にない場合、MITM攻撃を構築することは困難です。さらに確実にするために、他のすべてのデバイスを削除するか、コンピュータとリモートコンピュータの間にポイントツーポイントリンクを作成してみてください（この状況では、アドレス指定とDHCPが問題になる可能性があります）。
ルーターが信頼できないと思われる場合は、ルーターがシステムにルートと名前（DNS/mDNS/WINS）を通知できることを覚えておいてください。通常、システムは暗黙的に信頼するだけです。インターネットが方程式から外れることができるならば、それらが内部的に促進されない限り、そのようなルーティング/リダイレクションのトリックはプレイすることができません。
...「信頼のコンピューティング」は非常に大きなトピックであり、ここにあなたを送ることができる非常に多くの道があります...私は励ましますあなたが尋ねる/読む/遊ぶ/など...それは学ぶための最良の方法です。
他の回答ですでに議論されているように...あなたがここであなた自身を見つける最も可能性の高い状況は、
- Raspberry Piにオペレーティングシステムを再インストールした
- DHCPサーバーが、以前に
sshを使用して別のホストに与えられたリースを配布しましたが、これは最近Raspberry Piに与えられました
通常、人々は最初の接続で表示される指紋を受け入れ、将来的にそれで満足します。
特に感知システムでは、最初の接続で指紋が正確に正しいことを確認する必要があります。
フィンガープリントが変更された場合、ホストに関する何かが変更されています。たとえば、詐称者や再インストールなどです。
メッセージは基本的に、以前に特定のIP /アドレスで別のコンピューターに接続していることを意味します。
なぜこれがMITM以外にも発生するのですか？コンピュータが再インストールされた可能性があります。おそらく、別のコンピュータをIPに配置して、メッセージを完全に予期している可能性があります。
完全にLAN経由でルーティングされる接続のコンテキストでは、害のない理由ではなく実際の攻撃の確率はvery lowです。