私はUbuntuサーバー上でssh-copy-id myuser@myserver
を使ってパスワードなしのSSHをセットアップしようとしていますが、エラーが出ます。
警告: 'myserver'のECDSAホストキーはIPアドレス '192.168.1.123'のキーと異なります
何が原因で、それをどのように修正すればよいですか?リモートマシンの.ssh
ディレクトリを削除してssh-keygen -R "myserver"
をローカルで実行しようとしましたが、これでエラーは解決しません。
ローカルマシン上の192.168.1.123
のキャッシュされたキーを削除します。
ssh-keygen -R 192.168.1.123
私の場合、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行目( "問題のあるキー")を削除しました。私は再接続しようとしました、ホストは恒久的に追加されました、そしてその後すべてが大丈夫でした!
私は自分の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
を実行しました)
ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123
これにより、known_hosts.oldの下にある既存のキーを置き換えて、新しいキーを作成します。この解決策は同じシナリオで私のために働いた
動的アドレス指定を使用するとIPアドレスが常に変更されるため、毎回プロンプトが表示されます。静的IPを使用して、鍵を1回だけ追加すればよいようにします。
接続に同じユーザーを使用していますか?
あなたが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
こちらのスレッドが役に立ちます。
基本的には、そのHostのRSAキーとECDSAキーの両方を削除してから、この競合が発生しないようにssh-keyscan
を使用してそれらをknown_hosts
ファイルに戻す必要があります。私は同じ問題を抱えていたときそれは私のために働いた。
私は〜/ .ssh/configに以下の行を追加しました、それですべての.localアドレスに対する厳密なホストチェックを無効にしました。 (DHCPアドレス割り当てでは、私のローカルマシンのIPアドレスは常に変化しています)
Host *.local
StrictHostKeyChecking no
あなたはまだ警告を受けます、それは私によって大丈夫です。
このエラーは長い間私を悩ませ続けました。どういうわけかそれは私がやるかどうかの違いを生んだ
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 を参照してください。
質問:これが原因で何が起こるのでしょうか。
そのため、SSHサーバーのホストキーが変更されました。何が変わったのですか?言うのは難しいです。ここにいくつかの推測があります:
質問:...そしてどのように修正すればよいですか。
他の人が既に回答しているので、あなたのアカウントがキャッシュしたmyserverのキャッシュされたECDSA Hostキーを削除してください。
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 から借用したものです。
Secure Shellをアンインストールして再インストールすることで、Chromebookでこれを修正しました。