web-dev-qa-db-ja.com

ECDSA Hostキーに関する警告を修正する方法

私はUbuntuサーバー上でssh-copy-id myuser@myserverを使ってパスワードなしのSSHをセットアップしようとしていますが、エラーが出ます。

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

何が原因で、それをどのように修正すればよいですか?リモートマシンの.sshディレクトリを削除してssh-keygen -R "myserver"をローカルで実行しようとしましたが、これでエラーは解決しません。

264
Cerin

ローカルマシン上の192.168.1.123のキャッシュされたキーを削除します。

ssh-keygen -R 192.168.1.123
385
grawity

私の場合、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行目( "問題のあるキー")を削除しました。私は再接続しようとしました、ホストは恒久的に追加されました、そしてその後すべてが大丈夫でした!

58
aardvarkk

私は自分のLANコンピュータと私の2つのWebホスティングアカウントの間でたくさんのやりとりをしているので、ssh -vを使った認証の問題を含め、あらゆる種類の問題を解決しました。

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

私の場合のトリガーは、次のとおりです。職場で新しいサーバーOSをインストールし、openssh-serverパッケージをインストールすると、職場のサーバーで新しいHostキーのセットが生成されました。以前は、私のサーバーOSはすべてUbuntuで、今回はDebianに変更されました(そして、パーミッションに微妙な違いがあるのではないかと思います)。

すべてのOSがUbuntuで、最初にSSHを起動したときにサーバのOSを再インストールすると、この種の警告が表示されます。これは、上記のサイレント警告よりも優先されます。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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/known_hosts sshを起動しているコンピュータで、その行を削除して再接続すると、次のようになります。

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

そうです、おそらく、最近のUbuntuの変更に基づいて、最近Hostがecdsaキーを使用し始めたのですが、私はアップデートを非難するでしょう。 Ubuntuが私が頼りにしていた堅実なLinux OSから離れたのは、私が今回Debianをインストールした理由です。

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

17
Chris K

ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

これにより、known_hosts.oldの下にある既存のキーを置き換えて、新しいキーを作成します。この解決策は同じシナリオで私のために働いた

5
Jignesh Rawal

動的アドレス指定を使用するとIPアドレスが常に変更されるため、毎回プロンプトが表示されます。静的IPを使用して、鍵を1回だけ追加すればよいようにします。

4
Gaurav Joseph

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

あなたがuser JohnのようにローカルPCにログインし、user Adolf @ BのようにサーバBに接続していて、すべて問題ない場合ユーザJaneのようにローカルPCにログインし、ユーザAdolf @ BのようにサーバBに接続すれば、すべて問題ありません。

パスワードなしで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

こちらのスレッドが役に立ちます。

基本的には、そのHostのRSAキーとECDSAキーの両方を削除してから、この競合が発生しないようにssh-keyscanを使用してそれらをknown_hostsファイルに戻す必要があります。私は同じ問題を抱えていたときそれは私のために働いた。

1

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

Host *.local
    StrictHostKeyChecking no

あなたはまだ警告を受けます、それは私によって大丈夫です。

1
KimSJ

このエラーは長い間私を悩ませ続けました。どういうわけかそれは私がやるかどうかの違いを生んだ

ssh Host

または

ssh Host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-Host-key-checking-in-ssh

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

1
Wolfgang Fahl

質問:これが原因で何が起こるのでしょうか。

そのため、SSHサーバーのホストキーが変更されました。何が変わったのですか?言うのは難しいです。ここにいくつかの推測があります:

  • Myserver上のsshdはECDSA鍵を使い始めました。それでは新しい鍵タイプですか?
  • Myserverは最近再インストールされましたか?
  • Myserverのsshdが最近再インストールされたため、新しいssh Hostキーが生成されましたか?
  • 誰かがsshd Hostキーを再生成または置き換えましたか?
  • 別のホストがそのIPアドレスに応答しているように、myserverのIPアドレスが変更されましたか?

質問:...そしてどのように修正すればよいですか。

他の人が既に回答しているので、あなたのアカウントがキャッシュしたmyserverのキャッシュされたECDSA Hostキーを削除してください。

1
Lars Nordin

Chrome OSで既知のホストフィンガープリントを(known_hostsファイルから)削除する方法は次のとおりです。

接続が失敗したときのssh出力で、問題のあるHostエントリのインデックスを見つけます。たとえば、下の行では問題のあるインデックスは7です。

Offending ECDSA key in /.ssh/known_hosts:7

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

term_.command.removeKnownHostByIndex(INDEX);

この解決策は Leo Gaggl's Blog から借用したものです。

0
Alex Yursha

Secure Shellをアンインストールして再インストールすることで、Chromebookでこれを修正しました。

0
msersen