EC2 インスタンスの sshd_config ファイルに変更を加えたら、SSH を使用してインスタンスにアクセスできなくなりました。このエラーの解決方法を教えてください。

簡単な説明

インスタンスの sshd_config ファイルを変更すると、SSH 経由で接続するときに Connection Refused エラーが発生する原因になる場合があります。

Connection Refused エラーが原因でインスタンスにアクセスできないことを確認するには、以下の詳細なメッセージングを使用して、SSH 経由でインスタンスにアクセスします。

$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvv

上記の例では、プライベートキーファイルに myawskey.pem を使用し、ユーザー名として ec2-user@ec2.11.22.33.44 を使用しています。例にあるキーファイルとユーザー名を、お使いのキーファイルとユーザー名に置き換えてください。インスタンスがあるリージョンを使用していることを確認してください。

以下の出力例は、Connection Refused エラーメッセージを示しています。

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22.
ssh: connect to host ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22: Connection refused

解決方法

注意: Nitro ベースのインスタンスを使用している場合は、デバイス名が以下のステップで使用されている例のものとは異なります。例えば、Nitro ベースのインスタンス上のデバイス名は、/dev/xvda や /dev/sda1 ではなく、/dev/nvme になります。詳細については、「Linux インスタンス上のデバイス名」を参照してください。

方法 1: EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールを有効にした場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動問題、ネットワーク設定、および SSH 設定問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。シリアルコンソールには、Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用してアクセスできます。

シリアルコンソールを使用する前に、アカウントレベルでコンソールにアクセス権を付与します。その後、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。また、シリアルコンソールを使用するすべてのインスタンスには、少なくとも 1 名のパスワードベースユーザーを含める必要があります。インスタンスが到達不能で、シリアルコンソールへのアクセスが設定されていない場合は、次の「方法 2: レスキューインスタンスを使用する」セクションにある手順に従ってください。Linux 用の EC2 シリアルコンソールの設定の詳細については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

注意: AWS CLI コマンドの実行時にエラーが表示される場合は、AWS CLI の最新バージョンを使用していることを確認してください。

方法 2: レスキューインスタンスを使用する

警告: インスタンスの停止と起動を行う前に、以下の点を理解しておいてください。

• インスタンスが Instance Store-Backed である場合、またはデータを含むインスタンスストアボリュームがインスタンスにある場合、インスタンスを停止するとデータが失われます。詳細については、インスタンスのルートデバイスタイプの判別をご参照ください。
• インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止するとインスタンスが終了することがあります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk で起動されたインスタンスは、AWS Auto Scaling グループの一部である可能性があります。このシナリオでのインスタンスの終了は、Auto Scaling グループのインスタンスのスケールイン保護の設定に応じて異なります。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に、一時的に Auto Scaling グループからインスタンスを削除してください。
• インスタンスを停止および再開すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスに外部トラフィックをルーティングするときは、パブリック IP アドレスではなく Elastic IP アドレスを使用することがベストプラクティスです。Route 53 を使用している場合は、パブリック IP が変更されたときに Route 53 DNS レコードを更新する必要がある場合があります。

1.    Virtual Private Cloud (VPC) で新しい EC2 インスタンスを起動します。障害が発生したインスタンスと同じアベイラビリティーゾーンにある同じ Amazon マシンイメージ (AMI) を使用します。新しいインスタンスがレスキューインスタンスになります。

2.    障害が発生したインスタンスを停止します。

注: インスタンスが Instance Store-Backed である、またはデータを含むインスタンスストアボリュームがある場合は、インスタンスを停止するとデータが失われます。詳細については、インスタンスのルートデバイスタイプの判別をご参照ください。

3.    障害が発生したインスタンスから、Amazon Elastic Block Store (Amazon EBS) ルートボリューム (/dev/xvda または /dev/sda1) をデタッチします。

4.    レスキューインスタンスに、セカンダリデバイス (/dev/sdf) として EBS ボリュームをアタッチします。

5.    SSH を使用してレスキューインスタンスに接続します。

6.    lsblk コマンドを実行してデバイスを表示します。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
 └─xvdf1 202:81   0   8G  0 part

7.    ステップ 4 でレスキューインスタンスにアタッチした新しいボリュームのマウントポイントディレクトリ (/rescue) を作成します。

$ sudo mkdir /mnt/rescue

8.    ステップ 7 で作成したディレクトリにボリュームをマウントします。

$ sudo mount -t xfs -o nouuid /dev/xvdf1 /mnt/rescue/

ext3 および ext4 ファイルシステムをマウントするには、次のコマンドを実行します。

$ sudo mount /dev/xvdf1 /mnt/rescue

注: 前述の mount コマンドの構文は異なる場合があります。詳細については、man mount コマンドを実行してください。

9.    lsblk コマンドをもう一度実行して、ボリュームがディレクトリにマウントされたことを確認します。

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
└─xvdf1 202:81   0   8G  0 part /mnt/rescue

sshd_config ファイルを修正またはコピーする

障害が発生したインスタンスにある sshd_config ファイルを調べて、変更をロールバックできます。SSH 詳細メッセージングの出力を使用して、ファイル内のエラーの場所を確認します。

$ sudo vi /mnt/rescue/etc/ssh/sshd_config

または、以下のコマンドを使用して、sshd_config ファイルをレスキューインスタンスから障害が発生したインスタンスにコピーします。このコマンドは、元のインスタンスの sshd_config ファイルの内容を置き換えます。

$ sudo cp /etc/ssh/sshd_config /mnt/resscue/etc/ssh/sshd_config

ボリュームを元のインスタンスに再度アタッチして接続をテストする

注意: 「方法 2: レスキューインスタンスを使用する」を使用した場合は、以下の手順を完了してください。

1.    umount コマンドを実行して、ボリュームをアンマウントします。

$ sudo umount /mnt/rescue/

2.    レスキューインスタンスからセカンダリボリュームをデタッチして、そのボリュームを /dev/xvda (ルートボリューム) として元のインスタンスにアタッチします。

3.    インスタンスを起動します。

4.    SSH を使用してインスタンスに接続し、インスタンスに到達できることを確認します。

---

関連情報

SSH を使用した Amazon EC2 Linux インスタンスへの接続問題に関するトラブルシューティングはどのように行えばいいですか?