ssh_exchange_identification:でリモートに接続できない問題の原因と対処

システム
エンジニア

ssh_exchange_identification:でリモートに接続できない原因を知りたいです。

プロジェクト
マネージャー

リモートに接続できない原因はいくつかありますので紹介します。

みなさんはsshコマンドを使ってサーバに接続しようとした際にssh_exchange_identification: connection closed by remote hostというエラーが表示された経験はないでしょうか。

今回はこのエラーが発生する代表的なケースを2つ紹介し、それの根本原因と対処方法について述べていきます。また、いずれのケースにも該当しない場合のトラブルシューティングについても紹介します。

以下、接続元となるPCないしはサーバをローカル、sshで接続したい先のサーバのことをリモートと呼びます。

ケース1：REMOTE HOST IDENTIFICATION HAS CHANGED

以下の様なメッセージがssh_exchange_identification: connection closed by remote hostと併せて表示されている場合について紹介いたします。この場合は、リモートとローカルのknown_hostsファイルに記録されているfingerprintが異なっている可能性があります。

まず、fingerprintとは何か、それが記録されているknown_hostsファイルについて述べていきます。

known_hostsファイルとは何か

known_hostsファイルには過去に接続したことのあるホストごとにfingerprintと呼ばれる情報が記録されています。fingerprintとは接続先のホストのIPアドレス、鍵の暗号方式、公開鍵のことを指します。

sshの際には単にリモートのホスト名だけではなく、これらの情報と合わせて識別を行っており、名前の通り指紋の役割として働いています。

何らかの理由により、fingerprintが異なる場合 REMOTE HOST IDENTIFICATION HAS CHANGED! というエラーが出るというわけです。

known_hostsに記録されたfingerprintが変わってしまう原因としては、サーバが再起動したことによってDHCPによりIPアドレスが変わったり、OS再インストールによって公開鍵が変わったりと様々です。

リモートの情報が変更された理由に心当たりがある場合は以下の2つの方法で対処が可能です。一方で、心当たりがない場合はなりすましの可能性があるので注意が必要です。

対処：known_hostsに記録されたfingerprintを削除する

リモートが更新された原因に心当たりが場合は、直接known_hostsファイルに記録されたfingerprintを削除してしまっても問題ありません。

エディタでローカルのknown_hostsファイルを開き、該当のリモートホストから続く1行を削除することでssh_exchange_identification:connectionclosedbyremotehostエラーが解消されます。

以下のsedコマンドを使って削除することも可能です。

消されてしまったfingerprintについては、再びsshで接続したタイミングで新しいfingerprintが記録されるので問題ありません。

対処：REMOTE HOST IDENTIFICATION HAS CHANGED!の警告を無視する

また、known_hostsを編集せずとも、sshコマンド実行時に-o ‘StrictHostKeyChecking no’オプションをつけることでssh_exchange_identification:connectionclosedbyremotehostを無視して接続することができます。

このオプションをつけることでyes/noなどの対話も不要になるため、Pythonやshellscriptを用いてsshを実行するような場合にとても有効です。

ケース2：リモートの接続設定でconnection closed by remote hostが発生

sshd（ローカルからのssh接続を受け持つデーモン）やdenyHostsというセキュリティツールで禁止されている場合でもssh_exchange_identification:connectionclosedbyremotehostが発生する可能性があります。

ケース1に該当しない場合はリモートサーバのアクセス設定が不適切である可能性があります。

対処：リモートのアクセス設定を見直す

セキュリティツールによってリモートへのアクセス管理がされている場合、接続拒否設定ファイルの見直しが必要です。

具体的には／etc／hosts.denyファイルで管理されており、そのファイル内にローカルのIPアドレスが記述されていないか確認が必要です。

また、拒否とは別に許可を設定する／etc／hosts.allowというファイルもあります。この設定は／etc／hosts.denyよりも優先されます。

そのためセキュリティの観点から、拒否設定はできるかぎりそのままにし、／etc／hosts.allowに許可したいローカルのIPアドレスを指定することを推奨します。

以下のようにテキストエディタを使って修正することでssh_exchange_identification:connectionclosedbyremotehostエラーの発生を防ぐことができます。

アクセス設定を管理しているデーモンを再起動することで設定を反映することができます。
いずれのツールで管理しているかわからない場合はstatusコマンドで起動しているかどうか確認することを推奨します。

いずれのケースにも当てはまらない場合

ssh_exchange_identification:connectionclosedbyremotehostの原因が分からない場合のトラブルシューティングについて紹介していきます。

リモートにはsshdのログが記録されていますので、ログを見ることで何が原因で接続ができないのか確認することができます。

CentOS系のサーバであれば／var／log／secure、Ubuntu系のサーバであれば／var／log／auth.logに記録されています。接続を試みたユーザや日付、IPアドレスなどが記録されています。

また、／etc／ssh／sshd_configでLogLevelを設定することができます。LogLevelをDEBUGに変更することでより細やかな情報を得ることができます。

ただし、無用にレベルを下げることはプライバシの観点で注意が必要です。あくまで一時的な調査のために用いることを推奨します。

システム
エンジニア

エラーになる原因や対処方法がわかりました。

プロジェクト
マネージャー

エラーが出た際は、紹介した原因や対象方法を参考にしてみてください。

ssh_exchange_identificationのエラーまとめ

今回はssh_exchange_identification:connectionclosedbyremotehostのエラーとその原因・対処について2つほど紹介しました。加えて、いずれの原因にも当てはまらない場合のトラブルシューティングの方法について述べました。

まず1点目は、リモートのfingerprintが変わった場合について紹介しました。その対処方法として、ローカルに記録されているfingerprintを削除する、sshコマンドのオプションを利用して無視する、の2つを挙げました。

続いて2点目はリモートから拒絶されている場合について紹介しました。リモートの接続設定を見直すという対処方法を挙げました。

最後にいずれのケースにも当てはまらない場合のトラブルシューティングについて述べました。リモートのsshdが残しているログファイルを確認することでssh_exchange_identification:connectionclosedbyremotehostが発生した原因の特定を行うことができます。