SSHで厳密なRSAキーチェックを削除する方法と、ここでの問題は何ですか?


41

Linuxサーバーがあり、接続するたびにSSHホストキーを変更したメッセージが表示されます。

$ ssh root @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@ @警告:リモートホストの識別が変更されました!@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ ITは、誰かが厄介なことをしている可能性があります。誰かがあなたを盗聴している可能性があります(中間者攻撃)!RSAホストキーが変更された可能性もあります。リモートホストから送信されるRSAキーのフィンガープリントは93:a2:1b:1c:5f:3e:68:47:bf:79:56:52:f0:ec:03:6bです。システム管理者に連絡してください。このメッセージを削除するには、/ home / emerson / .ssh / known_hostsに正しいホストキーを追加します。/home/emerson/.ssh/known_hosts:377の問題のあるキー

host1のRSAホストキーが変更され、厳密なチェックを要求しました。ホストキーの検証に失敗しました。

数秒間ログインしたままになり、接続を閉じます。

host1:〜/ .ssh#リモートホストhost1からの読み取り:ピアによる接続のリセットhost1への接続が閉じられました。

誰が何が起こっているのか、この問題を解決するために私が何ができるかを知っていますか?


1
これは、以前の質問をdupes:serverfault.com/questions/2988/...
ドリュースティーブンス

回答:


67

一部の人が推奨するように、known_hostsファイル全体を削除しないでください。これは警告のポイントを完全に無効にします。中間攻撃者が発生した可能性があることを警告するセキュリティ機能です。

何かが変更されたと考える理由を特定することをお勧めします。SSHのアップグレードにより、セキュリティホールの可能性があるため、暗号化キーが変更された可能性があります。その後、known_hostsファイルからその特定の行を削除できます。

sed -i 377d ~/.ssh/known_hosts

このDの警告でコロンの後に示されているようeletesライン377:

/home/emerson/.ssh/known_hosts:377

または、次の手順を実行して関連キーを削除できます

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

ファイル全体をパージしないでください。特定のキーをパージする前に、これが実際に接続するマシンであることを確認してください。


1つのキーが一致しないため、350を超えるサーバーを削除しません。接続を閉じ続ける理由は何ですか?
瀬田高橋2009年

関連するknown_hostsレコードを削除すると解決しませんか?そうでない場合は、sshクライアントを冗長モードで実行して、どこかに貼り付けてください。
アダムギビンズ

1
ホストキーが無効であるため、マシンが閉じています。セキュリティについて真剣に考えている場合は、サーバーの管理者に問い合わせて、正当な理由でホストキーが変更されていることを確認する必要があります。その場合、アダムが説明したように、交換できます。
マシューFlaschen

私はあなたの提案に従いましたが、$ sed -i "46 d"〜/ .ssh / known_hosts sed:1: "/Users/myusr/.ssh ...":lコマンドの最後に余分な文字があるので、手動で削除しましたvimとそれは働いた。ありがとう!
ルイスラミレスモンテローザ

3
Adamの構文はほぼ正しいですが、「377」と「d」の間にスペースが必要です。また、OS Xでは、既知のホストは〜/ .ssh / known_hostsにあります。「。」がないことに注意してください ファイル名に。
ktappe

27

ここでの回答のいくつかは、OPの質問の推奨される行動方針に対応していますが、完全に質問に答えているわけではありません。

質問には、「SSHで厳密なRSAキーチェックを削除する方法と、ここでの問題は何ですか?」

ここでの問題は、他の一部からアドバイスされているように、おそらくサーバーの再インストールによるホストの変更です(最も一般的なシナリオ)。推奨される解決策は、実際にインラインsedを使用して.ssh / authorized_keysファイルから問題のあるキーを削除することです。

ただし、「SSHで厳密なRSAキーチェックを削除する方法」という質問の特定の部分に関する回答はありませんでした。

ssh構成ファイル(通常はに格納されています)でStrictHostKeyチェックを削除できます~/.ssh/config

ホストブロックの例を以下に示します。

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

特に追加された行は、StrictHostKeyChecking noまさにそれを行う最後の行です。特定のシナリオによっては、専用サーバー上で複数の仮想化コンテナーを実行し、少数のIPで実行し、同じIPで別のインスタンスを停止および開始するなど、これが役立つ場合があります。


3
+1この投稿は、実際にはエラーメッセージの厳密なチェック部分に対応しているためです。
渋見

1
質問の内容に対処するために私からも+1。要因に応じて、さらにやることがあります。このアプローチは、ホストチェックを「厳密」から「一部」に低下させます(私の用語)。私がログインしたい方法はパスワードを入力することでしたので、sshにサインインを許可する許可が残った私の状況では、「いくつかの」ホストチェックによって無効にされました。ですから、sshに「UserKnownHostsFile」として/ dev / nullを使用するよう指示する必要があります。これにより、ホストチェックが「なし」に設定され、上記のDIRE WARNINGSが適用されるため、グローバルまたは永続的に実行しないでください。
カーディフスペースマン

これは本当にエレガントなソリューションです。共有してくれてありがとう!
レオン-ハン李

10

StrictHostKeyCheckingを削除する別の方法は、単一サーバーに対してのみ行う必要がある場合です。

ssh <server> -o StrictHostKeyChecking=no

ログインできるようになりますが、問題を永久に修正することはできません。
アンドレスカネラ

私はそれを行うとき、それは私にそして永久に問題を修正し、キーを追加する機会を与える
グレッグ・ドハティ

おそらく別の問題がありますか?以前に別のIPを使用していたサーバーに接続しています。
アンドレスカネラ

データが変更されたサーバーがある場合、既知のホストファイルからサーバーを削除し(変更が正しいことを最初に確認した後)、その新しい情報を追加する必要があります。新しいサーバーがある場合は、-oを使用してサーバーに接続し、その情報を追加できます。
グレッグ・ドウアーティ

StrictHostKeyCheckingを設定でYESに設定したまま、新しいサーバーに接続していることがわかっている場合、または古いサーバーのキーを変更した場合にのみこのスイッチを使用することをお勧めします。
モハク

5

まず、これはあなたのマシンですか?ホストキーを故意に変更しましたか?そうでない場合、何かがそのデータを変更したことを非常に心配するでしょう。

次に、sshデバッグを有効にします。

ssh -vvv user@host

そして、それが何を伝えるかを確認し、接続しようとしているサーバー上の/ var / log / secureと/ var / log / messagesを調べてみてください。

第三に、このマシンはインターネットに接続されていますか?あなたは本当にルートログインを許可すべきですか?


1
ルートログインコメントの+1
Fahad Sadah

このエラーが発生するのに必要なのは、イメージを再作成するターゲットマシンだけです。DMZの側にあるターゲットに接続している場合、MitM攻撃はほとんどありません。
ktappe

3

これは、何かが変更されたために取得しています(新しいNIC、新しいIP、サーバーソフトウェアの変更など)。セキュリティフォーカスには、SSHホストキー保護に関する素晴らしい記事があります

$HOME/.ssh/known_hostsファイルを編集してサーバーからキーを削除し(SFTPなどを使用)、次の接続時に新しいキーを受け入れます。

StrictHostKeyCheckingの設定が原因で、接続がドロップされている可能性があります。同様の問題については、このスレッドを参照してください。


2
いや、これはしないでください。これにより、この機能が提供するすべてのセキュリティが完全に無効になります。すべてのknown_hostsではなく、変更された特定のキーのみを削除してください。
アダムギビンズ

5
known_hostsファイルを削除することはお勧めしませんでした。編集して、キーを削除することをお勧めします。

おっと、間違えた。
アダムギビンズ

2
このメッセージは、確かに新しいIPアドレスではトリガーできず、新しいNICではトリガーできません。Adam Gibbinsの正解をご覧ください。
ボルツマイヤー09年

1
投票する前に(これに非常に満足している人を見つけています)、調査を行います。このSecurity Focus記事securityfocus.com/infocus/1806を読んでください。「ホストキーを変更できるのはなぜですか?接続したいマシンが別のDNS名またはIPアドレスに移動されたか、完全に新しいものに置き換えられました。」答えが恐ろしく間違っている場合、訂正の機会を与えてください。結局のところ、これはウィキです。

3

「ホスト」(広く定義されているように、再インストール/マルチブートから、以前に接続したIPアドレスを持つ完全に異なるコンピューターなど)がsshクライアントに変更されたように見えます。エラー。

厳密なチェックをオフにする必要はなく、保存されたキーの大規模な削除も適切です。

特定のホスト名またはIPアドレスについて、known_hostsに2つの異なるキーをリストすることは非常に可能です。known_hostsに現在保存されている「古い」キーが必要かどうかに応じて、2つの選択肢を提供します。

OPのknown_hostsのl377で参照している特定のキーを削除するか、両方を保持します

known_hostsのキーの削除を避けて、両方を保持する最も簡単な方法は

  1. known_hostsを編集して、known_hosts [@ l377]で一時的に参照される「古い」エントリの先頭に#を追加します
  2. [sshをホストに接続]、新しいキーを「自動的に」追加するプロンプトに同意します
  3. その後、known_hostsを再編集して#を削除します

でより多くの回答のホスト名あたり/複数のSSHホスト鍵「をknown_hostsファイルに正しいホストキーを追加しますか」?


2つのキーのトリックについては知りませんでした。これは文書化された動作ではありませんか?
hackerb9
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.