877
784

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

SSH接続エラー回避方法:.ssh/known_hostsから特定のホストを削除する/削除しないで対処する3つの方法

Last updated at Posted at 2014-02-28

(2014年02月28日:初投稿)
(2020年01月24日:Ubuntu 18.04 LTS で動作確認)

ssh接続エラー(ワーニング)になり接続できないことがある。

  • エラー原因のknown_hostsの設定削除する方法
  • 手軽にエラーを無視する方法
  • エラーとならないようにサーバ側を設定する方法
    について記載する。
    ただし、これらの方法がセキュリティ的によいのかは各自判断が必要。

ssh接続先サーバがOSを再インストールしたとか、接続先サーバがDHCPでアドレスが変わるとか、接続先サーバがホスト名を付け替えたとか、そういったときに次のエラー(ワーニング)が発生して接続ができない。

接続エラー
$ ssh remote_host
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
29:24:c2:69:a3:b0:dc:4d:23:fc:9d:85:9f:ea:01:9b.
Please contact your system administrator.
Add correct host key in /home/grgrjnjn/.ssh/known_hosts to get rid of this message.
Offending key in /home/grgrjnjn/.ssh/known_hosts:3
RSA host key for remote_host has changed and you have requested strict checking.
Host key verification failed.

なぜ?

SSHでは、安全な接続を行うために接続先サーバの情報(RSA公開鍵のフィンガープリント)を、クライアントは保存する。SSH接続時には、以前保存したこの情報と、いままさに接続しようとしているサーバの情報が一致しているかを確認する。こうすることで、ユーザ(クライアント)が知らない間に、別のサーバへ接続してしまうことを防ぐ。よりセキュアになるってわけだ。

エラー原因のknown_hostsの設定削除する方法

保存している接続先サーバの情報(フィンガープリント)を削除してしまえば、新規接続となるためエラーを回避できる。そのコマンドは、ssh-keygen -R hostnameで行うのが正解。.oldを付けてバックアップも自動で作られる。

正解
$ ssh-keygen -R remote_host_name
/home/grgrjnjn/.ssh/known_hosts updated.
Original contents retained as /home/grgrjnjn/.ssh/known_hosts.old

実態は~/.ssh/known_hostsファイルなので、直接編集しても良い。エラーとなったサーバ名(またはIPアドレス)から始まる行を1行削除するだけ。

sedを使ってもよいだろう。

sedを使ったやり方
$ sed -i '/remote_host_name/d' ~/.ssh/known_hosts

単に、viで編集してもダメではない。

手軽にエラーを無視する方法

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!が発生しても無視して接続するのは、接続時に-o 'StrictHostKeyChecking no'オプションを使う方法と、このオプションを設定ファイルに記載して常に有効にする方法がある。

エラーを無視する接続方法
$ ssh -o 'StrictHostKeyChecking no' remote_host_name
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for remote_host_name has changed,
and the key for the corresponding IP address 10.211.55.28
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/grgrjnjn/.ssh/known_hosts:1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
29:24:c2:69:a3:b0:dc:4d:23:fc:9d:85:9f:ea:01:9b.
Please contact your system administrator.
Add correct host key in /home/grgrjnjn/.ssh/known_hosts to get rid of this message.
Offending key in /home/grgrjnjn/.ssh/known_hosts:3
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Last login: Fri Feb 28 15:27:36 2014 from 10.211.55.27

上記のコマンド実行結果をよく見るとわかるように、この方法を使うと、エラーとともに、次のような初回接続時の(yes/no)?の対話的なやりとりも省略できる。

この対話処理も省略される
$ ssh remote_host_name
The authenticity of host 'remote_host_name (10.211.55.28)' can't be established.
RSA key fingerprint is 29:24:c2:69:a3:b0:dc:4d:23:fc:9d:85:9f:ea:01:9b.
Are you sure you want to continue connecting (yes/no)? 

常にこのオプションを有効にしたいなら設定ファイルにStrictHostKeyChecking noを記載する。システム全体に適用したいなら、/etc/ssh/ssh_configに、ユーザ毎に設定したいなら~/.ssh/configに、次のように記載する。

~/.ssh/config
StrictHostKeyChecking no

~/.ssh/configがなければ新規に作成する。その場合、パーミッションに注意。このファイルのパーミッションは600でないと、SSH接続時にエラーとなる。

~/.ssh/configのパーミッション設定
$ chmod 600 ~/.ssh/config

この設定がされていると、次のように警告は出るがエラーで止まることもなく、対話的な応答もすることなく、接続される。

StrictHostKeyCheckingが設定されている場合の挙動
$ ssh remote_host_name
Warning: Permanently added 'remote_host_name' (RSA) to the list of known hosts.
Last login: Fri Feb 28 15:32:12 2014 from 10.211.55.27

この動作をさせるなら、言うまでもないが、セキュリティ的なリスクについては十分に検討してもらいたい。

エラーとならないようにサーバ側を設定する方法

接続先サーバ側のRSA公開鍵のフィンガープリントが変わってしまうことが原因なら、変わらないようにするという手もある。フィンガープリントの元ネタは/etc/ssh/ssh_host_key.pubなどがこれにあたる。

これらをバックアップしておいてOS再インストール後に戻してやるとか、複数サーバで共有するとか、してやればいい。

RHEL、CentOSの場合
/etc/ssh/moduli
/etc/ssh/ssh_config
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/sshd_config

バックアップから戻すときの参考に、私のCentOS6.5の環境ではパーミッションは以下の通りになっている。

CentOS6.5のパーミッション
$ ls -ld /etc/ssh/
drwxr-xr-x. 2 root root 4096  2月 11 21:06 2014 /etc/ssh/

$ ls -l /etc/ssh/
合計 156
-rw-------. 1 root root 125811 11月 23 07:40 2013 moduli
-rw-r--r--. 1 root root   2047 11月 23 07:40 2013 ssh_config
-rw-------. 1 root root    668  2月 11 19:21 2014 ssh_host_dsa_key
-rw-r--r--. 1 root root    590  2月 11 19:21 2014 ssh_host_dsa_key.pub
-rw-------. 1 root root    963  2月 11 19:21 2014 ssh_host_key
-rw-r--r--. 1 root root    627  2月 11 19:21 2014 ssh_host_key.pub
-rw-------. 1 root root   1675  2月 11 19:21 2014 ssh_host_rsa_key
-rw-r--r--. 1 root root    382  2月 11 19:21 2014 ssh_host_rsa_key.pub
-rw-------. 1 root root   3879  2月 11 21:06 2014 sshd_config

以上

[OpenSSH[実践]入門(Amazon)
OpenSSH[実践]入門

877
784
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
877
784

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?