New user sign up using AWS Builder ID
New user sign up using AWS Builder ID is currently unavailable on re:Post. To sign up, please use the AWS Management Console instead.
インスタンスの sshd_config ファイルを変更した後、SSH を使用して EC2 インスタンスにアクセスする方法を教えてください。
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの sshd_config ファイルを変更しましたが、SSH を使用してインスタンスにアクセスできなくなりました。
簡単な説明
インスタンスの** sshd\ _config** ファイルを変更すると、SSH 経由で接続するときに接続拒否エラーが発生する可能性があります。
接続拒否エラーが原因でインスタンスにアクセスできないことを確認するには、詳細メッセージをオンにして SSH 経由でインスタンスにアクセスします。次の例を参照してください。
$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvv
この例では DNS 名で接続し、プライベートキーファイルにはmyawskey.pem を使用し、ユーザー名は ec2-user とします。例にあるキーファイルとユーザー名を、お使いのキーファイルとユーザー名に置き換えてください。
次の出力例は、接続拒否エラーメッセージを示しています。
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: レスキューインスタンスを使用する
警告:
- インスタンスがインスタンスストアでバックアップされている場合、またはデータを含むインスタンスストアボリュームがある場合、インスタンスを停止するとデータは失われます。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
- インスタンスが Amazon EC2 Auto Scaling グループの一部である場合、インスタンスを停止するとインスタンスが終了する可能性があります。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用して起動するインスタンスは、AWS Auto Scaling グループの一部である可能性があります。このシナリオでインスタンスが削除されるかどうかは、Auto Scaling グループのインスタンススケールイン保護の設定によって異なります。インスタンスが Auto Scaling グループの一部である場合は、解決のためのステップを開始する前に、Auto Scaling グループからインスタンスを一時的に削除します。
- インスタンスを停止および再開すると、インスタンスのパブリック IP アドレスが変更されます。インスタンスを再起動または終了したときに EC2 パブリック IP アドレスを変更したくない場合は、Elastic IP アドレスを使用してください。Amazon Route 53 を使用している場合は、パブリック IP が変更されたときに Route 53 の DNS レコードを更新しなければならない場合があります。
1. 仮想プライベートクラウド (VPC) で新しい EC2 インスタンスを起動します。障害が発生したインスタンスと同じアベイラビリティーゾーンにある同じ Amazon マシンイメージ (AMI) を使用します。新しいインスタンスがレスキューインスタンスになります。
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/rescue/etc/ssh/sshd_config
ボリュームを元のインスタンスに再度アタッチして接続をテストする
注:方法 2 を使用した場合**: レスキューインスタンスを使用して**、次のステップを完了します。
1. umount コマンドを実行して、ボリュームをアンマウントします。
$ sudo umount /mnt/rescue/
2. レスキューインスタンスからセカンダリボリュームをデタッチして、そのボリュームを /dev/xvda (ルートボリューム) として元のインスタンスにアタッチします。
3. インスタンスを起動します。
4. SSH を使用してインスタンスに接続し、インスタンスに到達できることを確認します。
関連情報

関連するコンテンツ
- 質問済み 2年前lg...
- 質問済み 1年前lg...
- 質問済み 4ヶ月前lg...
- 質問済み 1年前lg...
- AWS公式更新しました 5ヶ月前