SSH を使用して EC2 インスタンスに接続する際、「Connection refused」または「Connection timed out」エラーが発生する場合のトラブルシューティング方法を教えてください。

所要時間3分

SSH を使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに接続する際、「Connection refused」または「Connection timed out」というエラーが発生します。

簡単な説明

接続がタイムアウトすると、SSH クライアントから次のエラーメッセージが表示されます。

「ssh: connect to host ec2-X-X-X-X.compute-1.amazonaws.com port 22: Connection timed out」

Connection timed out エラーは、サーバーがクライアントに応答せず、クライアントプログラムが再試行しなくなった (タイムアウト) 場合に発生します。

ホストがリモートで接続を拒否した場合は、次のエラーメッセージが表示されます。

「ssh: connect to host ec2-X-X-X-X.compute-1.amazonaws.com port 22: Connection refused」

解決策

「Connection timed out」エラー

Connection timed out エラーが発生した場合は、次の設定を確認してください。

インスタンスの IP アドレスまたはホスト名が正確である。
インスタンスはヘルスチェックに合格した。
インスタンスのセキュリティグループが、インバウンドトラフィックを TCP ポート 22 で許可している。
インスタンスのサブネットのネットワークアクセスコントロールリスト (ネットワーク ACL) は、インバウンドトラフィックを TCP ポート 22 で許可し、アウトバウンドトラフィックをエフェメラルポートで許可している。
インスタンスのサブネットのルートテーブルでは、インスタンスと SSH クライアント間の接続を指定している。
SSH クライアントとインスタンス間の接続をブロックするファイアウォールは存在しない。
インスタンスの TCP Wrapper は SSH をブロックしていない。詳細については、Red Hat のウェブサイトで「2.6.2.TCP Wrapper 設定ファイル」を参照してください。

注: ファイアウォールまたは TCP Wrapper の問題を確認するには、オペレーティングシステム (OS) がインスタンスにアクセスできる必要があります。

「Connection refused」エラー

Connection refused エラーが発生する場合、次の設定を確認します。

インスタンスには SSH 接続をブロックするファイアウォールは存在しない。
SSH デーモン (sshd) が実行中で、ポート 22 でリッスンしている。

注: 上記の設定を確認するには、インスタンスへの OS レベルのアクセス許可が必要です。

両方のヘルスチェックに合格したインスタンスでの問題のトラブルシューティング

ヘルスチェックに合格したインスタンスの問題をトラブルシューティングするには、次のトラブルシューティング方法のいずれかを使用します。

AWSSupport-TroubleshootSSH ランブックを実行する

AWSSupport-TroubleshootSSH オートメーションランブックを実行することをおすすめします。このランブックは Amazon EC2Rescue ツールをインスタンスにインストールし、Linux ホストへのリモート SSH 接続をブロックしている問題を特定し、修正します。

Linux 用 EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールを使用すると、サポートされているインスタンスタイプでの起動に関する問題、ネットワーク設定の問題、SSH 設定の問題などの OS レベルの問題をトラブルシューティングできます。

前提条件

AWS アカウントレベルでコンソールへのアクセスを許可します。
IAM ユーザーにコンソールへのアクセス許可を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。
注: EC2 シリアルコンソールを使用する各インスタンスには、sudo アクセスを持つ、パスワードベースの Linux ユーザーが少なくとも 1 人必要です。

詳細については、「EC2 シリアルコンソールへのアクセス許可を設定する」を参照してください。

ログインパスワードが設定済みの Linux アカウントがない場合、ssm-user を実行し、sudo アクセスを持つアカウントのパスワードをリセットする必要があります。

設定が SSH アクセスをブロックしていないことを確認するには、次の手順を実行します。

EC2 シリアルコンソールを使用して、パスワードが設定された Linux ユーザーで EC2 インスタンスに接続します。
iptables ルールを設定した場合は、次のコマンドを実行し、すべての SSH 接続をポート 22 で受け入れるルールを iptables に追加します。
```
sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
```
OS ベースのファイアウォールを使用している場合は、無効にしてください。ファイアウォールではなく、セキュリティグループを使用することをおすすめします。OS ベースのファイアウォールを無効にするには、お使いの OS に応じて次のコマンドを実行します。
重要: 次のコマンドは、主な iptables ルールをすべてクリアし、既存のルールを削除します。さらに、このコマンドは、インバウンド SSH 接続を許可するルールを追加し、メインチェーンのデフォルトポリシーを ACCEPT に変更します。この設定では、iptables ルールをクリアしても、インスタンスのネットワーク接続は影響を受けません。
Ubuntu、Debian などの UFW を使用するディストリビューション:
```
sudo iptables -F$ sudo iptables -P INPUT ACCEPT
sudo ufw disable
```
Red Hat Enterprise Linux (RHEL)、CentOS などの firewalld を使用するディストリビューション:
```
sudo iptables -F $ sudo iptables -P INPUT ACCEPT
sudo systemctl disable firewalld
```
注: インスタンスへのアクセスを復旧した後、ファイアウォールの設定を確認します。

SSH が実行中で、SSH の TCP ポート 22 がリスニング状態であることを確認するには、次のコマンドを実行します。

sudo systemctl restart sshd$ sudo ss -tpln | grep -iE '22|ssh'LISTEN 0 128 *:22 *:* users:(("sshd",pid=1901,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1901,fd=4))

注: システムで ss コマンドを使用できない場合は、ss を従来の netstat コマンドに置き換えてください。上記のコマンドと同じ構文を使用してください。

TCP Wrapper が SSH 接続をブロックしないようにするには、次のコマンドを実行します。

if [[ $( cat /etc/hosts.[ad]* | grep -vE '^#' | awk 'NF' | wc -l) -ne 0 ]];\
then sudo sed -i '1i sshd2 sshd : ALL: allow' /etc/hosts.allow; fi

SSH を使用してインスタンスに接続します。
EC2 シリアルコンソールのセッションから切断します。

Systems Manager を使用する

前提条件 AWS Systems Manager の機能である Session Manager を使用するには、インスタンスはマネージドノードである必要があります。インスタンスの AWS Systems Manager Agent (SSM Agent) では、ping ステータスが Online である必要があり、アタッチされた IAM ロールには AmazonSSMManagedInstanceCore アクセス許可が必要です。Session Manager の前提条件をすべて満たしていることを確認してください。

Session Manager を使用してセッションを開始し、インスタンスにアクセスします。

ユーザーデータスクリプトを使用する

上記のトラブルシューティング方法を使用できない場合は、ユーザーデータスクリプトを使用して OS レベルのファイアウォールと TCP Wrapper を無効化します。sshd サービスを再起動します。

重要: インスタンスを停止して起動する前に、次の手順を実行します。

Amazon Elastic Block Store (Amazon EBS) ボリュームのバックアップを作成します。
注: インスタンスの基盤がインスタンスストアであるか、データを含むインスタンスストアボリュームがある場合、インスタンスの停止時に Amazon EC2 はデータを削除します。
解決手順の実行時に、Amazon EC2 Auto Scaling グループからインスタンスを一時的に除外します。
注: EC2 Auto Scaling グループ内のインスタンスを停止する場合、インスタンスがスケールイン保護設定に基づいて削除される場合があります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用して起動するインスタンスが、Auto Scaling グループに属している可能性があります。
インスタンスのシャットダウン動作を Stop に設定し、インスタンスの停止時にインスタンスが削除されないようにします。

注: インスタンスを停止または起動する際、インスタンスのパブリック IP アドレスは変更されます。外部トラフィックをインスタンスにルーティングするには、パブリック IP アドレスではなく Elastic IP アドレスを使用することをおすすめします。

インスタンスのユーザーデータを設定するには、次の手順を実行します。

Amazon EC2 コンソールを開きます。
ナビゲーションペインで [インスタンス] を選択し、該当するインスタンスを選択します。
インスタンスを停止します。
[アクション] を選択し、[インスタンス設定] を選択します。

[ユーザーデータの編集] を選択し、次のユーザーデータスクリプトを入力します。

Content-Type: multipart/mixed; boundary="//"MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type:
    text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
iptables -P INPUT ACCEPT
iptables -F
systemctl restart sshd.service || service sshd restart
if [[ $( cat /etc/hosts.[ad]* | grep -vE '^#' | awk 'NF' | wc -l) -ne 0 ]];\
then sudo sed -i '1i sshd2 sshd : ALL: allow' /etc/hosts.allow; fi
--//

注: 上記のユーザーデータスクリプトは、インスタンスを再起動するたびに実行されるように設定されています。この方法では、すべての主要な iptables ルールは削除されます。

[保存] を選択します。
SSH を使用してインスタンスに接続します。
インスタンスへのアクセスを復旧した後、ユーザーデータスクリプトを削除し、ファイアウォールの設定が正確であることを確認します。

SSH を使用して EC2 インスタンスに接続する際、「Connection refused」または「Connection timed out」エラーが発生する場合のトラブルシューティング方法を教えてください。

簡単な説明

解決策

「Connection timed out」エラー

「Connection refused」エラー

両方のヘルスチェックに合格したインスタンスでの問題のトラブルシューティング

関連情報

関連ビデオ

関連するコンテンツ