ssh – ECDSA ホスト鍵に関する警告を修正する方法

security ssh ssh-keys ubuntu-server

UbuntuのサーバでパスワードなしのSSHをssh-copy-id myuser@myserverで設定しようとしているのですが、エラーが出てしまいます

警告: ‘myserver’ の ECDSA ホストキーは、IP アドレス ‘192.168.1.123’ のキーとは異なります

何が原因で発生しているのでしょうか?リモートマシンの .ssh ディレクトリを削除し、ローカルで ssh-keygen -R "myserver" を実行してみましたが、エラーが解決しません

  345  Cerin  2012-05-05


ベストアンサー

ローカルマシン上の192.168.1.123のキャッシュされたキーを削除してください

ssh-keygen -R 192.168.1.123

518  user1686  2012-05-05


私の場合はssh-keygen -R ...では警告が直りませんでした。こんな感じで余計な情報が入っていました

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

私は単に手動で~/.ssh/known_hostsを編集し、8行目(「違反キー」)を削除しました。再接続を試みたところ、ホストは永久に追加され、その後はすべて問題ありませんでした!

83  aardvarkk  2014-03-11


私は自分の LAN コンピュータと 2 つのウェブホスティングアカウントの間で たくさんの ssh を使っています

この問題を解決したばかりで、答えに満足していない私は、本当に自分自身の「なぜ」を知りたいと思っていました

私の場合のきっかけは、職場に新しいサーバOSをインストールし、openssh-serverパッケージをインストールした際に、職場のサーバに新しいホストキーが生成されたことです。以前は全てのサーバOSがUbuntuだったのですが、今回はDebianに変更されました(パーミッションに微妙な違いがあるのではないかと疑っています)

全てのOSがUbuntuで、サーバのOSを再インストールした時に、最初にSSHで入った時に、このような警告が出ます

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

その後、ssh を起動しているコンピュータで ~/.ssh/known_hosts を開き、その行を削除して再接続すると、このようなことが起こります

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

:11122 は、ファイアウォール上で SSH をルーティングするポート番号です

以前のUbuntuサーバからのバックアップを確認し、新しいDebianのインストールと比較してみました

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

そうですね、おそらく、ホストが最近 ecdsa キーを使い始めたのでしょう、最近の Ubuntu の変化に基づいて、私はアップデートのせいにするでしょう。私が頼りにしていた岩のように強固なLinux OSから離れたUbuntuのシフトは、私が今回Debianをインストールした理由です

ecdsa の security.SE q/a を読んで、sshd_config の新しい Debian サーバからその行を削除しました (そして service ssh restart を実行しました)。(そして service ssh restart を実行しました)

21  Chris K  2014-01-16


ダイナミックアドレッシングを使用している場合、IPアドレスが常に変化するため、毎回プロンプトが発生します。一度だけキーを追加するだけで済むように、静的IPを使用するようにしてください

8  Gaurav Joseph  2014-01-16


ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.123

これは known_hosts.old の下にある既存の鍵を置き換えて新しい鍵を作成します。この解決策は、同じシナリオで私の場合はうまくいきました

7  Jignesh Rawal  2015-05-14


次の行を ~/.ssh/config に追加して、すべての .local アドレスに対する厳格なホストチェックを無効にしました。(DHCP アドレスの割り当てでは、ローカルマシンの ip アドレスは常に変化しています)

host *.local
StrictHostKeyChecking no

警告が出るのはいいんだけどね

7  KimSJ  2018-03-15


接続には同じユーザーを使用していますか?

ユーザーJohnのようなローカルPCにログインして、ユーザーAdolf@BのようなサーバーBに接続していて、すべてがOKであれば、ユーザーJaneのようなローカルPCにログインして、ユーザーAdolf@BのようなサーバーBに接続していても、すべてがOKというわけではありません

PC AからユーザBedaとしてサーバBにパスワードなしでログインしたい場合は、すべてPC Aからこのコマンドを試してみてください

ssh-keygen -t rsa

このコマンドは、鍵を生成してファイルに保存します。パスフレーズは空欄にしてください

ssh Beda@B mkdir -p .ssh

このコマンドは、まだ存在しない場合は、ディレクトリを作成します。そうでなければ、エラーメッセージを表示しません

cd ~/.ssh

このコマンドは、ディレクトリをユーザーのホームディレクトリ ./ssh に変更します

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

このコマンドは、ファイル id_rsa.pub (あなたの公開鍵) をサーバ上の authorized_keys に出力します

重要: Beda は接続しているサーバー上のユーザー名、B はサーバーの IP です

これで、パスワードやパスフレーズなしでサーバーBに接続できるようになりました

ssh Beda@B

2  Petr Derian  2014-10-21


スレッドこちらが参考になるかもしれません

本質的には、そのホストの RSA 鍵と ECDSA 鍵の両方を削除して、ssh-keyscanを使って、この衝突を起こさないように known_hosts ファイルに戻したいのです。私が同じ問題を抱えていたときは、これで解決しました

1  Paul A Jungwirth  2012-12-20


質問です。何が原因なんでしょうか・・・?

ということで、sshサーバのホスト鍵が変更されました。何が原因で変更されたのでしょうか?答えるのは難しいです。ここにいくつかの推測があります

  • myserver の sshd は ECDSA 鍵を使うようになったので、新しい鍵の種類になったのでしょうか?
  • myserver は最近再インストールされましたか?
  • myserver の sshd が最近再インストールされたので、新しい ssh ホスト鍵が生成されたのでしょうか?
  • 誰かが sshd ホスト鍵を再生成または交換したのでしょうか?
  • myserver の IP アドレスを変更して、その IP アドレスに別のホストが応答するようになったのでしょうか?

質問:……どうやって直せばいいですか?

他の方がすでに回答されているように、アカウントにキャッシュされている myserver の ECDSA ホストキーを削除してください

1  Lars Nordin  2012-08-07


このエラーは長い間私を悩ませ続けました。何らかの理由で、それは私がaをするかどうかの違いを作った

ssh host

or

ssh host.domain
Attention Required! | Cloudflare

が設定ファイルを変更するオプションを教えてくれました。プロセスを自動化するための私のスクリプトhttps://askubuntu.com/a/949731/129227を参照してください

1  Wolfgang Fahl  2017-08-25


Chromebook でこの問題を解決するには、Secure Shell をアンインストールして再インストールする必要があります。それは魅力的なように動作しました

0  msersen  2015-05-18


ここでは、Chrome OSで既知のホストフィンガープリント(known_hostsファイルから)を削除する方法を紹介します

接続に失敗したときの ssh 出力で、問題のあるホストエントリのインデックスを見つけてください。例えば、以下の行では、違反しているインデックスは 7 です

Offending ECDSA key in /.ssh/known_hosts:7

Secure Shell ウィンドウの JavaScript コンソール (CTRL+Shift+J) を開き、INDEX を適切な値 (例: 7) に置き換えて以下のように入力します

term_.command.removeKnownHostByIndex(INDEX);

この解決策は、Leo Gaggl’s Blogから拝借しました

0  Alex Yursha  2017-07-24


私の側では、これは新しい (OpenSSH_7.9p1 以上の) クライアントの ssh バグだと思っていますが、より安全な ecdsa サーバ鍵を学習しようとしたときに、古い rsa タイプの鍵がすでに知られている場合に発生します。そして、このような誤解を招くようなメッセージを表示します!

私が見つけた唯一の回避策は、クライアントが「より安全な新しいecdsaキー」を再学習できるように、「良いが古いrsaキー」をすべて削除することです。これで、クライアントが「新しいより安全なecdsa鍵」を再学習できるようになる

  1. 最初のステップは、古き良きRSAキーをすべて削除することです(警告!これはMitMに対する保護を失います)

    $ sed -i '/ ssh-rsa /d' ~/.ssh/known_hosts
    
  2. 第二のステップは、すべてのホスト鍵を再学習することであり、これはsshを使って各IPに再度接続して手動で行わなければならない

Windows用に編集します

  • Windowsではsedは存在しないので、known_hostsファイルを削除するのが最善の方法でしょう

    del %USERPROFILE%\.ssh\known_hosts`
    
  • 警告!これはすべてのキーが再学習されるまで、MitMに対する保護を失います


私が観察しているのはこんな感じです

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp>

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>

次に、新しく導入されたこの同じ既に知られている良いサーバーのエイリアスに接続してみてください

$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

IPアドレスを見てみてください。上記と同じIPです!ということで、(既知の)IPの(良い)キーが突然自分自身を攻撃しているように見えます(そうではありません。sshクライアントが互換性のない2つのキーを混ぜているので、以下を参照)

今はそれを修正しようとしています

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

もう一回やってみましょう

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?

WTF?何が起きたんだ?サーバーから学習した新しい鍵が また失敗したのか?問題がすり替わったのか?

いや、鍵でもサーバーでもない。すべてが正しい!

正しいキーの検証に失敗したのは ssh クライアントです!known_hosts のエントリ 45ecdsa-sha2-nistp256 型のキーを持っていますが、クライアントによってサーバから引き出されたキーは rsa-sha2-512 型です (したがって、他のキーとは一致しません!)

$ sftp -v test@valentin.hilbig.de

shows:

debug1: kex: host key algorithm: rsa-sha2-512

while

$ sftp -v test@gcopy.net

shows:

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

どうやらsshクライアントにはどこかにバグがあるようです!ホスト鍵が複数のバリアントで存在する場合には対処できません!あるいは、古い鍵のバリアントを要求するという罠に陥ってしまいます

どうやって直すの?

本当に見当がつきません。これはおそらく上流でしか直せないのではないでしょうか

しかし、マニュアルはあるが不器用な回避策

rsa型の古いキーの痕跡をすべて手動で削除する必要があります。問題のキーは出力に表示されていますが、直接問題としてマークされているわけではありません

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

check:

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

gives

ecdsa-sha2-nistp256
ssh-rsa

ここでは、一致するホストキーは問題のあるキーであり、問題のあるキーは正しいキーであり、これを保持しなければなりません。そこで、間違った(マッチする)ホストキーを削除してみましょう

ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

今、もう一度確認してみてください

$ sftp test@valentin.hilbig.de
The authenticity of host 'valentin.hilbig.de (136.243.197.100)' can't be established.
ECDSA key fingerprint is SHA256:tf7lwe10C2p1lK2UG9p//m/4sUBCpX+i9k5Ub63c6Os.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'valentin.hilbig.de' (ECDSA) to the list of known hosts.
Connected to test@valentin.hilbig.de.
sftp>

$ sftp test@gcopy.net
Connected to test@gcopy.net.
sftp>

sftp test@136.243.197.100
Connected to test@136.243.197.100.
sftp>

やったー!ようやく問題が解決しました。しかし、.ssh/known_hostsに100個ものエントリがあると、この “解決策 “は本当に大きなPITAになってしまいます(そして、エルム街のエラーが起こりやすいセキュリティの悪夢です。YMMV.)

0  Tino  2020-02-23


タイトルとURLをコピーしました