簡単な説明

セカンダリ IP アドレスを使用して SSH 経由でインスタンスに接続する前に、インスタンスが次の前提条件を満たしていることを確認してください。

• プライベートサブネットでインスタンスを起動した場合は、セカンダリプライベート IP アドレスを使用して SSH 経由で接続します。必ず、ネットワークインターフェイス用のサブネットの IPv4 CIDR ブロック範囲から、セカンダリ IPv4 アドレスを選択してください。
• パブリックサブネットでインスタンスを起動した場合は、Elastic IP アドレスをインスタンスのセカンダリプライベート IP アドレスに割り当てます。
• EC2 インスタンスのオペレーティングシステムがセカンダリプライベート IP アドレスを認識していることを確認してください。Amazon Linux の場合は、「セカンダリプライベート IPv4 アドレスを認識するようにインスタンスのオペレーティングシステムを設定する」を参照してください。Ubuntu の場合は、「Ubuntu EC2 インスタンスでセカンダリネットワークインターフェイスを動作させるにはどうすればよいですか?」を参照してください。 その他の Linux ディストリビューションについては、ご利用のディストリビューションのネットワーク設定ドキュメントを参照してください。

インスタンスがこれらの前提条件を満たしている場合は、次の手順を使用して SSH 経由の接続問題をトラブルシューティングします。

1. 詳細メッセージをオンにして SSH 経由で接続し、エラーを特定します。
2. システムログを確認してエラーがないか調べます。
3. ネットワーク設定ファイルを確認します。

**注:**インスタンスとデータのバックアップを維持するのがベストプラクティスです。トラブルシューティングを行う前に、AMI を作成するか、Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットを作成します。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用しているかどうかを確認してください。また、開始する前に、一般的な接続の前提条件を確認してください。

詳細メッセージをオンにして SSH 経由で接続し、エラーを特定する

詳細な手順については、「SSH を使用した Amazon EC2 Linux インスタンスへの接続に関する問題をトラブルシューティングするにはどうすればよいですか?」を参照してください。

ネットワーク設定ファイルとシステムログを確認して、エラーがないか調べる

問題が解決しない場合は、インスタンスのシステムログを確認してください。以下の方法のいずれかを使用してログにアクセスし、インスタンスでさらにトラブルシューティングを行います。

方法 1: プライマリ IP アドレスを使用してインスタンスに接続する

1.    プライマリ IP アドレスを使用して SSH 経由でインスタンスにアクセスします。アクセスしたら、セカンダリネットワークインターフェイスのネットワークステータスと設定を確認します。そのためには、以下のコマンドを実行します。

ifconfig の出力を調べて、インスタンスのセカンダリネットワークインターフェイスが稼働していることを確認します。

$ ifconfig -a

または、次のコマンドを実行します。

$ ip a show < network interface name> up
Example Command:
$ ip a show eth1 up

**注:**この例では、セカンダリネットワークインターフェイスは eth1 です。これをセカンダリネットワークインターフェイスの名前に置き換えます。

2.    セカンダリネットワークインターフェイス設定ファイルを確認し、すべてのパラメータを検証します。たとえば、任意の MAC アドレス、セカンダリ IP アドレス、セカンダリインターフェイス名を確認できます。不一致が見つかった場合は、ファイルを編集して正しい情報に更新してください。次のコマンドのいずれかを実行します。

Linux、RHEL、CentOS:

$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth1

Ubuntu

sudo cat /etc/network/interfaces.d/51-eth1.cfg  
or  
sudo cat /etc/netplan/51-eth1.yaml

3.    次のコマンドを実行して、ネットワークサービスを再起動します。

$ sudo service network restart

問題が解決しない場合は、アクセスを試みた時点のシステムログと認証関連ログを確認してください。

方法 2: Amazon EC2 シリアルコンソールを使用してインスタンスにアクセスする

SSH 経由でプライマリ IP アドレスを使用してインスタンスにアクセスできない場合は、Linux 用 Amazon EC2 シリアルコンソールを使用してください。Amazon EC2 シリアルコンソールを使用して、サポートされている Nitro ベースおよびベアメタルのインスタンスタイプをトラブルシューティングできます。Amazon EC2 シリアルコンソールを使用する前に、Linux インスタンス用 Amazon EC2 シリアルコンソールと Amazon EC2 シリアルコンソールへのアクセスを設定することを確認してください。

方法 3: レスキューインスタンスを使用してネットワーク設定ファイルとログにアクセスする

**重要:**この方法を使用する前に、次の制限に注意してください。

• インスタンスを停止すると、インスタンスストアボリューム 上のデータはすべて消去されます。保持したいインスタンスストアボリューム上のデータをすべてバックアップする必要があります。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
• インスタンスが Amazon EC2 Auto Scaling グループの一部であるかどうかを確認します。Amazon EMR、AWS CloudFormation、または AWS Elastic Beanstalk を使用してインスタンスを起動した場合、そのインスタンスは AWS Auto Scaling グループの一部である可能性があります。このユースケースでは、インスタンスを停止すると、インスタンスが終了する可能性があります。インスタンスの終了は、Auto Scaling グループのインスタンススケールイン保護設定によって異なります。インスタンスが Auto Scaling グループの一部である場合は、解決手順を開始する前に Auto Scaling グループから一時的にインスタンスを削除します。
• インスタンスを停止して起動すると、インスタンスのパブリック IP アドレスが変更されます。外部トラフィックをインスタンスにルーティングするには、パブリック IP アドレスの代わりに Elastic IP アドレスを使用するのがベストプラクティスです。
• インスタンスのシャットダウン動作が 終了 に設定されているかどうかを確認します。つまり、オペレーティングシステムからシャットダウンコマンドまたはパワーオフコマンドを使用すると、インスタンスは終了します。これを回避するには、インスタンスのシャットダウン動作を変更してください。

レスキューインスタンスでネットワーク設定ファイルにアクセスするには、次の手順に従います。

1.    [Amazon EC2 コンソール] を開きます。

2.    ナビゲーションペインから [インスタンス] を選択し、接続する予定のインスタンスを選択します。

3.    [インスタンスの状態] を選択し、[インスタンスの停止] を選択します。

4.    [停止] を選択し、[インスタンス ID] をメモします。

注:新しい Amazon EC2 エクスペリエンスを使用しない場合は、接続するインスタンスを選択してください。[アクション] > [インスタンスの状態] > [停止] を選択し、もう一度 [停止] を選択します。

5.    停止したインスタンスからルート EBS ボリュームをデタッチします。ルート EBS ボリュームのデバイス名をメモします。デバイス名は、調査後にボリュームを再接続するときに必要です。

6.    元のインスタンスと同じアベイラビリティーゾーン (AZ) で新しい EC2 インスタンスを起動します。新しいインスタンスがレスキューインスタンスになります。

**注:**Amazon Linux 2 インスタンスをレスキューインスタンスとして使用するのがベストプラクティスです。これでは、EBS ボリュームの UUID または名前が同じであるため、アタッチされた EBS ボリュームからレスキューインスタンスを起動することはできません。

7.    レスキューインスタンスが起動したら、ナビゲーションペインから [ボリューム] を選択します。次に、障害が発生したインスタンスのデタッチされたルートボリュームを選択します。

**注:**インスタンスに AWS Marketplace コードがあり、Amazon Linux インスタンスではない場合は、ルート EBS ボリュームをアタッチする前にレスキューインスタンスを停止してください。例えば、公式の RHEL や CentOS AMI からインスタンスを起動した場合、インスタンスには AWS Marketplace コードが含まれている可能性があります。

8.    [アクション] を選択し、[ボリュームのアタッチ] を選択します。

9.    ナビゲーションペインで [インスタンス] を選択し、レスキューインスタンスを選択します。

10.    [インスタンスの状態] を選択し、[インスタンスを開始] を選択します。

注: 新しい Amazon EC2 エクスペリエンスを使用していない場合は、接続するインスタンスを選択し、[アクション] を選択します。[インスタンスの状態] を選択し、[開始] を選択します。

11.    SSH 経由でレスキューインスタンスに接続します。

12.    次のコマンドを実行して、EBS ボリュームがレスキューインスタンスに正常にアタッチされていることを確認します。次のコマンドでは、アタッチされたボリュームは /dev/sdf です。

$ lsblk

以下は、コマンド出力の例となります。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   20G  0 disk
└─xvda1 202:1    0   20G  0 part /
xvdf    202:80   0  100G  0 disk

13.次のコマンドを実行してマウントポイントディレクトリを作成し、アタッチされたボリュームをレスキューインスタンスにマウントします。次の例では、マウントポイントディレクトリは /test です。

$ sudo su
$ mkdir /test
$ mount /dev/xvdf1 /test

注: デバイス /dev/xvdf1 をマウントするときに、UUID の重複に関する問題が発生した場合は、前のコマンドを変更してコマンドを再実行してください。

$ mount -o nouuid /dev/xvdf1 /test
$ df -h
$ cd /test

14.    システムログと認証関連ログでエラーを検索します。タイムスタンプを使用して、アクセスを試みた時間のログを確認できます。

Amazon Linux、RHEL、CentOS:

$ sudo cat /test/var/log/messages

Amazon Linux、RHEL、CentOS (認証関連の問題):

$ sudo cat /test/var/log/secure

Ubuntu, Debian (システムログ):

$ sudo cat /test/var/log/syslog

Ubuntu、Debian (認証関連の問題):

$ sudo cat /test/var/log/auth.log

15.    この記事の方法 1 で説明したセカンダリネットワークインターフェイスファイルを確認してください。設定を確認してエラーを解決したら、EBS ルートボリュームをアンマウントし、レスキューインスタンスからデタッチします。

$ umount /test

16.    ボリュームを元のインスタンスにアタッチします。デバイス名は /dev/xvda です。

関連情報

SSH クライアントを使用して Linux インスタンスに接続する