【解決済み】ssh_exchange_identification: read: Connection reset by peer エラーの直し方

「ssh_exchange_identification: read: Connection reset by peer」というエラーは比較的まれなものですが、Unix系サーバーへSSH接続を試みた際に遭遇することがあります。WindowsでCygwinを使ってUbuntuにアクセスする場合でも、macOSのターミナルからArch、Fedora、CentOSに接続する場合でも同様です。SSHはUnixやLinux全般で共通して使われているため、リモートサーバー側が許可なく接続をリセットした瞬間に、このエラーはいつでも発生しえます。

方法1：hosts.denyファイルを確認する

サーバーの管理者権限があり、直接アクセスできる手段があるなら、最も簡単な解決策は、サーバー本体に直接ログインした状態でhosts.denyファイルを確認することです。

サーバー上で次のコマンドを実行し、自分のマシンが何らかの理由で拒否リストに載っていないかチェックしましょう。

もし自分のマシンが記載されていれば、それは通常誤登録です。安全にその行を削除してから、別のマシンからSSHで再接続してみてください。記載がない場合は、自分のマシンの接続を妨げるような不審なワイルドカード指定がないかも確認してください。ただし、多くの場合、ディストリビューションが初期状態で用意したデフォルトのテキストしかないファイルが原因になることはほとんどありません。

リモートログインを手動で許可したい場合は、次のコマンドでホワイトリストに追記する方法もあります。 この操作はめったに必要ありませんが、追記する場合はディストリビューションがファイル内に記載している説明文に従ってください。たとえば、ファイルの末尾に「ALL: appuals.com」という行を追加すれば、appuals.comのすべてのユーザーがサーバーへ接続できるようになります。ホスト名の入力ミスがないよう注意し、Ctrl+Oでファイルを保存、Ctrl+Xで終了してください。

これでSSH接続できるようになっているはずです。

方法2：SSH設定オプションを変更する

リモートサーバーにアクセスできない場合や、前述の方法で解決しなかったときは、古いSSH設定ファイルを一度クリアしてから、アップデート後に再試行してみてください。それでも改善しない場合は、sshコマンドに-vオプションを付けて再度接続を試みましょう。さらにエラーメッセージが表示されるようであれば、-c aes256-ctrをsshコマンドに追加してみてください。これにより暗号化方式の候補リストが短くなり、パケットサイズも小さくなるため、目的のサーバーに接続できる可能性が高まります。

一部のユーザーからは、この方法がCiscoブランド機器のトラブルシューティングで特に有効だったという報告があります。一部のサーバーハードウェアは、デフォルトでより小さなパケットサイズを前提としているためです。普段使っているsshコマンドに-c aes256-ctrを追加するだけで、接続できるようになるはずです。

方法3：誤ってかけられたIPブロックを解除する

以前に何度かログインを試みて拒否された経験がある場合、自分のサーバーがあなたを不正なIPアドレスと誤認している可能性があります。これはトラブルシューティング中に接続を繰り返し再試行したときに起こりがちです。合理的な対応ではありますが、fail2banのサブルーチンには攻撃のように見えてしまうことがあります。これを確認するには、リモート接続からsudo iptables -L --line-numberを実行し、自分のIPアドレスを探してください。おそらく、無視してよい無関係な接続ルールがいくつも表示されるでしょう。

問題となる箇所が見つかったら、iptables -Dに続けて該当するチェーン名とチェーン番号を指定して実行します。これにより、自分自身のソフトウェアによって再びブロックされるのを防げます。それでも問題が残る場合は、次のファイルを編集してください。

root権限でお好みのテキストエディタ（おそらくnanoかvi）でファイルを開き、 のようなコマンドを実行したうえで、「ignoreip」と書かれた行を探します。この行に自分のIPアドレスを追加すれば、fail2banが今後あなたのIPアドレスをブロックリストに追加することを恒久的に防げます。

Linuxディストリビューションによって挙動は多少異なりますが、これらの変更は大半の場合すぐに反映されます。