インスタンスへの接続に関するトラブルシューティング - Amazon Elastic Compute Cloud
接続の問題の一般的な原因インスタンスへの接続エラー: 接続タイムアウトエラー: キーを読み込めません... 期待: 任意のプライベートキーエラー: ユーザーキーがサーバーによって認識されないエラー: アクセス許可が拒否されたか、[インスタンス] ポート 22 によって接続が閉じられました。エラー: Unprotected Private Key File (保護されていないプライベートキーファイル)エラー: プライベートキーの先頭は「-----BEGIN RSA PRIVATE KEY-----」、末尾は「-----END RSA PRIVATE KEY-----」にする必要がありますエラー: Server refused our key または No supported authentication methods available (サーバーはキーを拒否しましたまたは利用可能なサポートされる認証方法はありません)インスタンスに対して ping を実行できないエラー: サーバーによる予期しないネットワーク接続の閉鎖エラー: EC2 Instance Connect のホストキーの検証に失敗しましたEC2 Instance·Connect を使用して Unbntu インスタンスに接続できないプライベートキーを紛失しました。Linux インスタンスに接続するにはどうすればよいですか?

インスタンスへの接続に関するトラブルシューティング

以下の情報と一般的なエラーは、Linux インスタンスへの接続に関するトラブルシューティングに役立ちます。

Windows インスタンスの接続のトラブルシューティングについては、「Windows インスタンスの Amazon EC2 ユーザーガイド」の「Windows インスタンスのトラブルシューティング」を参照してください。

接続の問題の一般的な原因

次のタスクを正確に実行したことを確認して、インスタンス接続の問題のトラブルシューティングを開始することをお勧めします。

インスタンスのユーザー名を確認する

インスタンスに接続するには、ユーザーアカウントのユーザー名、またはインスタンスの起動に使用した AMI のデフォルトのユーザー名を使用します。

  • ユーザーアカウントのユーザー名を取得します。

    ユーザーアカウントの作成方法については、「Linux インスタンスのユーザーアカウントを管理する」を参照してください。

  • インスタンスの起動に使用した AMI のデフォルトのユーザー名を取得します。

    インスタンスの起動に使用される AMI デフォルトユーザー名

    Amazon Linux 2022

    Amazon Linux 2

    Amazon Linux

    		 ec2-user
    CentOS centos または ec2-user
    Debian admin
    Fedora fedora、または ec2-user
    RHEL ec2-user、または root
    SUSE ec2-user、または root
    Ubuntu ubuntu
    Oracle ec2-user
    Bitnami bitnami
    その他 AMI プロバイダーに確認してください。
セキュリティグループルールでトラフィックが許可されていることを確認する

インスタンスに関連付けられているセキュリティグループで、IP アドレスからの受信 SSH トラフィックが許可されていることを確認します。VPC のデフォルトのセキュリティグループでは、着信 SSH トラフィックはデフォルトでは許可されません。インスタンス起動ウィザードで作成されたセキュリティグループでは、デフォルトで SSH トラフィックが許可されます。Linux インスタンスにインバウンド SSH トラフィックのルールを追加する手順については、「Linux インスタンス用のインバウンドトラフィックの承認」を参照してください。確認する手順については、「インスタンスへの接続エラー: 接続タイムアウト」を参照してください。

インスタンスが準備ができていることを確認する

インスタンスを起動してから接続できるようになるまでには、数分かかる場合があります。インスタンスをチェックして、それが実行中であり、ステータスチェックに合格していることを確認します。

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. 以下について確認してください。

    1. [インスタンスの状態] 列で、インスタンスの状態が running であることを確認します。

    2. [ステータスチェック] 列で、インスタンスが 2 つのステータスチェックに合格したことを確認します。

インスタンスに接続するための設定作業と前提条件を実行したことを確認する

一般的な設定作業については、「インスタンスへの接続を設定する」を参照してください。

SSH、EC2 Instance Connect、OpenSSH、PuTTY などの接続タイプに固有の前提条件については、以下のオプションを参照してください。

Linux または macOS X

ローカルコンピュータのオペレーティングシステムが Linux または macOS X の場合、次の接続オプション固有の前提条件を確認してください。

Windows

ローカルコンピュータのオペレーティングシステムが Windows の場合、次の接続オプション固有の前提条件を確認してください。

インスタンスへの接続エラー: 接続タイムアウト

インスタンスへ接続しようとして、エラーメッセージ Network error: Connection timed out または Error connecting to [instance], reason: -> Connection timed out: connect が表示される場合、次を実行します。

セキュリティグループルールを調べます。

ローカルコンピュータの適切なポートのパブリック IPv4 アドレスからのインバウンドトラフィックがセキュリティグループルールで許可されている必要があります。

New console

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. コンソールページの下部にある [セキュリティ] タブの [インバウンドルール] で、選択したインスタンスで有効なルールのリストを確認します。

    • Linux インスタンスの場合: ローカルコンピュータからポート 22 (SSH) へのトラフィックを許可するルールがあることを確認します。

    • Windows インスタンスの場合: ローカルコンピュータからポート 3389 (RDP) へのトラフィックを許可するルールがあることを確認します。

    セキュリティグループに、ローカルコンピュータからのインバウンドトラフィックを許可するルールがない場合は、セキュリティグループにルールを追加します。詳細については、「Linux インスタンス用のインバウンドトラフィックの承認」を参照してください。

  4. インバウンドトラフィックを許可するルールについては、[Source] (ソース) フィールドを確認します。値が単一の IP アドレスで、IP アドレスが静的でない場合、コンピュータを再起動するたびに新しい IP アドレスが割り当てられます。これにより、ルールにはコンピュータの IP アドレストラフィックが含まれなくなります。コンピュータが企業ネットワークにある場合またはインターネットサービスプロバイダー (ISP) を通じて接続する場合は、コンピュータの IP アドレスが静的ではない可能性があります。つまり、コンピュータの IP アドレスは動的で、コンピュータを再起動するたびに変化します。セキュリティグループルールで、ローカルコンピュータからのインバウンドトラフィックが許可されるようにするには、[Source] (ソース) に単一の IP アドレスを指定するのではなく、クライアントコンピュータで使用されている IP アドレスの範囲を指定します。

    セキュリティグループのルールの詳細については、Amazon VPCユーザーガイドの「セキュリティグループのルール」を参照してください。

Old console

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. コンソールページの下部の [Description] タブで、[Security groups] の横にある [view inbound rules] を選択して、選択されたインスタンスに対して有効なループのリストを表示します。

    • Linux インスタンスの場合: [ルールの表示] を選択すると、ウィンドウが開いて、トラフィックが許可されるポートが表示されます。ご使用のコンピュータからポート 22 (SSH) へのトラフィックを許可するルールがあることを確認します。

    • Windows インスタンスの場合: [ルールの表示] を選択すると、ウィンドウが開いて、トラフィックが許可されるポートが表示されます。ご使用のコンピュータからポート 3389 (RDP) へのトラフィックを許可するルールがあることを確認します。

    セキュリティグループにインバウンドトラフィックを許可するルールがない場合は、セキュリティグループにルールを追加します。詳細については、「Linux インスタンス用のインバウンドトラフィックの承認」を参照してください。

  4. ローカルコンピュータを再起動するたびに、新しい IP アドレス (およびホスト名) が割り当てられる可能性があります。セキュリティグループに、単一の IP アドレスからのインバウンドトラフィックを許可するルールがあっても、コンピュータが企業ネットワークにある場合またはインターネットサービスプロバイダー (ISP) を通じて接続する場合は、このアドレスが静的ではない可能性があります。この場合は、クライアントコンピュータで使用されている IP アドレスの範囲を指定します。

    セキュリティグループのルールの詳細については、Amazon VPCユーザーガイドの「セキュリティグループのルール」を参照してください。
サブネットのルートテーブルを確認します。

VPC の外部あてのすべてのトラフィックを VPC のインターネットゲートウェイに送信するには、ルートが必要です。

New console

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. [ネットワーキング] タブで、VPC ID とサブネット ID の値を書き留めます。

  4. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  5. ナビゲーションペインで、[Internet Gateways] を選択します。ご使用の VPC にアタッチされているインターネットゲートウェイがあることを確認します。または、[インターネットゲートウェイの作成] を選択し、インターネットゲートウェイの名前を入力して [インターネットゲートウェイの作成] を選択します。次に、作成したインターネットゲートウェイで、[アクション]、[VPC にアタッチ]、[VPC] の順に選択し、[インターネットゲートウェイのアタッチ] をクリックして VPC にアタッチします。

  6. ナビゲーションペインで [Subnets] を選択し、サブネットを選択します。

  7. [ルートテーブル] タブで、送信先として 0.0.0.0/0、ターゲットとして VPC のインターネットゲートウェイが指定されたルートがあることを確認します。IPv6 アドレスを使用してインスタンスに接続する場合は、インターネットゲートウェイを指しているすべての IPv6 トラフィック (::/0) 用のルートがあることを確認します。それ以外の場合は、以下の作業を行います。

    1. ルートテーブルの ID (rtb-xxxxxxxx) を選択して、ルートテーブルに移動します。

    2. [Routes] タブで、[Edit routes] を選択します。[Add route] を選択して、0.0.0.0/0 を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。IPv6 の場合は、[Add route] を選択して、::/0 を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。

    3. [Save routes] を選択します。

Old console

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. [Description] タブで、[VPC ID] および [Subnet ID] の値を書き留めます。

  4. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  5. ナビゲーションペインで、[Internet Gateways] を選択します。ご使用の VPC にアタッチされているインターネットゲートウェイがあることを確認します。それ外の場合は、[Create Internet Gateway] を選択してインターネットゲートウェイを作成します。インターネットゲートウェイを選択し、[VPC にアタッチ] を選択して指示どおりにインターネットゲートウェイを VPC にアタッチします。

  6. ナビゲーションペインで [Subnets] を選択し、サブネットを選択します。

  7. [Route Table] タブで、送信先として 0.0.0.0/0、ターゲットとして VPC のインターネットゲートウェイが指定されたルートがあることを確認します。IPv6 アドレスを使用してインスタンスに接続する場合は、インターネットゲートウェイを指しているすべての IPv6 トラフィック (::/0) 用のルートがあることを確認します。それ以外の場合は、以下の作業を行います。

    1. ルートテーブルの ID (rtb-xxxxxxxx) を選択して、ルートテーブルに移動します。

    2. [Routes] タブで、[Edit routes] を選択します。[Add route] を選択して、0.0.0.0/0 を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。IPv6 の場合は、[Add route] を選択して、::/0 を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。

    3. [Save routes] を選択します。
サブネットのネットワークアクセスコントロールリスト (ACL) を確認します。

ネットワーク ACL では、ローカル IP アドレスからのインバウンドトラフィックが、ポート 22 (Linux インスタンスの場合)、またはポート 3389 (Windows インスタンスの場合) で許可されている必要があります。また、一時ポート (1024-65535) へのアウトバウンドトラフィックも許可する必要があります。

  1. Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開きます。

  2. ナビゲーションペインで、[Subnets (サブネット)] を選択します。

  3. サブネットを選択する

  4. [ネットワーク ACL] タブの [インバウンドルール] で、必要なポートでコンピュータからのインバウンドトラフィックを許可しているルールがあることを確認します。それが見つからない場合は、コンピュータへのトラフィックをブロックしているルールを削除または変更します。

  5. [アウトバウンドルール] で、一時ポートでコンピュータへのトラフィックを許可しているルールがあることを確認します。存在しない場合は、コンピュータへのトラフィックをブロックしているルールを削除または変更します。

コンピュータが社内ネットワークに接続されている場合

社内ファイアウォールで、ご使用のコンピュータのインバウンドおよびアウトバウンドのトラフィックがポート 22 (Linux インスタンスの場合) またはポート 3389 (Windows インスタンスの場合) で許可されているかどうか、ネットワーク管理者に問い合わせてください。

ご使用のコンピュータにファイアウォールが設定されている場合、そのファイアウォールでコンピュータのインバウンドおよびアウトバウンドのトラフィックがポート 22 (Linux インスタンスの場合) またはポート 3389 (Windows インスタンスの場合) で許可されているかどうか確認します。

インスタンスにパブリック IPv4 アドレスがあることを確認します。

そうでない場合は、Elastic IP アドレスをインスタンスに関連付けることができます。詳細については、「Elastic IP アドレス」を参照してください。

サーバーが過負荷になっている可能性のあるインスタンスの CPU 負荷を確認します。

AWS は自動的に Amazon CloudWatch メトリクスおよびインスタンスステータスなどのデータを提供します。これらを使用することでインスタンスの CPU 負荷を確認でき、必要に応じて負荷の処理方法を調整できます。詳細については、「CloudWatch を使用したインスタンスのモニタリング」を参照してください。

IPv6 アドレスを使用してインスタンスに接続するには、以下のことを確認します。

  • サブネットはインターネットゲートウェイへの IPv6 トラフィック (::/0) のルートを持つルートテーブルに関連付けられている必要があります。

  • セキュリティグループルールでは、適切なポート (Linux の場合は 22、Windows の場合は 3389) のローカル IPv6 アドレスからの着信トラフィックを許可する必要があります。

  • ネットワーク ACL ルールでは、インバウンドおよびアウトバウンドの IPv6 トラフィックを許可する必要があります。

  • 古い AMI からインスタンスを起動した場合、DHCPv6 用に設定されていない可能性があります (IPv6 アドレスはネットワークインターフェイスでは自動的に認識されません)。詳細については、「インスタンスでの IPv6 の設定」 (Amazon VPC ユーザーガイド) を参照してください。

  • ローカルコンピュータに IPv6 アドレスがあり、IPv6 を使用するように設定されている必要があります。

エラー: キーを読み込めません... 期待: 任意のプライベートキー

インスタンスに接続しようとして、エラーメッセージ、unable to load key ... Expecting: ANY PRIVATE KEY が表示される場合、プライベートキーが保存されているファイルが正しく設定されていません。プライベートキーファイルが .pem で終わる場合でも、正しく設定されていない可能性があります。プライベートキーファイルが正しく設定されていない原因として考えられるのは、証明書がないことです。

プライベートキーファイルが正しく設定されていない場合は、以下の手順に従ってエラーを解決する

  1. 新しいキーペアを作成します。詳細については、「Amazon EC2 を使用してキーペアを作成する」を参照してください。

    注記

    サードパーティー製のツールを使用して、新しいキーペアを作成することもできます。詳細については、「サードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートする」を参照してください。

  2. 新しいキーペアをインスタンスに追加します。詳細については、「プライベートキーを紛失しました。Linux インスタンスに接続するにはどうすればよいですか?」を参照してください。

  3. 新しいキーペアを使用してインスタンスに接続します。

エラー: ユーザーキーがサーバーによって認識されない

SSH を使用してインスタンスに接続している場合

  • ssh -vvv を使用して、接続中に 3 倍詳細デバッグ情報を取得します。

    ssh -vvv -i path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com

    次のサンプル出力は、サーバーが認識しないキーを使用してインスタンスに接続しようとした場合に表示される可能性があります。

    open/ANT/myusername/.ssh/known_hosts).
debug2: bits set: 504/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: boguspem.pem ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: boguspem.pem
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA 9c:4c:bc:0c:d0:5c:c7:92:6c:8e:9b:16:e4:43:d8:b2
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
PuTTY を使用してインスタンスに接続している場合

  • 秘密キー (.pem) ファイルが PuTTY によって認識される形式 (.ppk) に変換されていることを確認します。プライベートキーの変換の詳細については、「PuTTY を使用した Windows から Linux インスタンスへの接続」を参照してください。

    注記

    PuTTYgen でプライベートキーファイルをロードし、[Generate] ではなく [Save Private Key] を選択します。

  • AMI 用の適切なユーザー名で接続していることを確認します。[PuTTY Configuration] ウィンドウの [Host name] ボックスにユーザー名を入力します。

    インスタンスの起動に使用される AMI デフォルトユーザー名

    Amazon Linux 2022

    Amazon Linux 2

    Amazon Linux

    		 ec2-user
    CentOS centos または ec2-user
    Debian admin
    Fedora fedora、または ec2-user
    RHEL ec2-user、または root
    SUSE ec2-user、または root
    Ubuntu ubuntu
    Oracle ec2-user
    Bitnami bitnami
    その他 AMI プロバイダーに確認してください。

  • 適切なポートへのインバウンドトラフィックを許可しているインバウンドセキュリティグループがあることを確認します。詳細については、「インスタンスへのネットワークアクセスの許可」を参照してください。

エラー: アクセス許可が拒否されたか、[インスタンス] ポート 22 によって接続が閉じられました。

SSH を使用してインスタンスに接続し、Host key not found in [directory]、Permission denied (publickey)、Authentication failed, permission denied、または Connection closed by [instance] port 22 のいずれかのエラーが発生した場合は、AMI 用の適切なユーザー名で接続しており、かつ、インスタンス用の適切なプライベートキー (.pem) ファイル) を指定していることを確認します。

適切なユーザー名は以下のとおりです。

インスタンスの起動に使用される AMI デフォルトユーザー名

Amazon Linux 2022

Amazon Linux 2

Amazon Linux

 ec2-user
CentOS centos または ec2-user
Debian admin
Fedora fedora、または ec2-user
RHEL ec2-user、または root
SUSE ec2-user、または root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
その他 AMI プロバイダーに確認してください。

例えば、SSH クライアントを使用して Amazon Linux インスタンスに接続するには、次のコマンドを使用します。

ssh -i /path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com

使用しているプライベートキーファイルが、インスタンスの起動時に選択したキーペアに対応していることを確認します。

New console

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. [詳細] タブの [インスタンスの詳細] で、[キーペア名] の値を確認します。

  4. インスタンスを起動したときにキーペアを指定しなかった場合は、キーペアを確実に指定するために、インスタンスを終了してから新しいインスタンスを起動します。それまで使用していたインスタンスで、キーペアに対する .pem ファイルがもう存在しない場合は、そのキーペアを新しいキーペアで置き換えることができます。詳細については、「プライベートキーを紛失しました。Linux インスタンスに接続するにはどうすればよいですか?」を参照してください。

Old console

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

  3. [Description] タブで、[Key pair name] の値を確認します。

  4. インスタンスを起動したときにキーペアを指定しなかった場合は、キーペアを確実に指定するために、インスタンスを終了してから新しいインスタンスを起動します。それまで使用していたインスタンスで、キーペアに対する .pem ファイルがもう存在しない場合は、そのキーペアを新しいキーペアで置き換えることができます。詳細については、「プライベートキーを紛失しました。Linux インスタンスに接続するにはどうすればよいですか?」を参照してください。

独自のキーペアを生成した場合は、キージェネレータが RSA キーを作成するように設定されていることを確認します。DSA キーは受け入れられません。

Permission denied (publickey) エラーが表示され、上のいずれも当てはまらない場合 (例えば、以前は接続できていたなど)、インスタンスのホームディレクトリのアクセス権限が変更された可能性があります。/home/instance-user-name/.ssh/authorized_keys のアクセス権限は、所有者のみに制限する必要があります。

インスタンスのアクセス権限を検証するには

  1. インスタンスを停止し、ルートボリュームをデタッチします。詳細については、インスタンスの停止と起動 および Linux インスタンスから Amazon EBS ボリュームをデタッチします。 を参照してください。

  2. 同じアベイラビリティーゾーンにある一時インスタンスを現在のインスタンスとして起動し (現在のインスタンスに使用したのと同様または同じ AMI を使用)、ルートボリュームを一時インスタンスにアタッチします。詳細については、「インスタンスへの Amazon EBS ボリュームのアタッチ」を参照してください。

  3. 一時インスタンスに接続してマウントポイントを作成し、アタッチしたボリュームをマウントします。詳細については、「Linux で Amazon EBS ボリュームを使用できるようにする」を参照してください。

  4. 一時インスタンスから、アタッチされたボリュームの /home/instance-user-name/ ディレクトリのアクセス権限をチェックします。必要に応じて、次のようにアクセス権限を調整します。

    [ec2-user ~]$ chmod 600 mount_point/home/instance-user-name/.ssh/authorized_keys
    [ec2-user ~]$ chmod 700 mount_point/home/instance-user-name/.ssh
    [ec2-user ~]$ chmod 700 mount_point/home/instance-user-name

  5. ボリュームをアンマウントして一時インスタンスからデタッチし、元のインスタンスに再アタッチします。ルートボリュームに適切なデバイス名を指定したことを確認します (/dev/xvda など)。

  6. インスタンスを起動します。一時インスタンスが必要なくなった場合は、終了できます。

エラー: Unprotected Private Key File (保護されていないプライベートキーファイル)

プライベートキーファイルはその他のすべてのユーザーの読み取りおよび書き込み操作から保護されている必要があります。プライベートキーがお客様以外のユーザーによって読み取りまたは書き込みできる場合、SSH はキーを無視し、次の警告メッセージが表示されます。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '.ssh/my_private_key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/my_private_key.pem
Permission denied (publickey).

インスタンスへのログインを試みたときに同様のメッセージが表示された場合は、エラーメッセージの最初の行を調べて、インスタンスに対して正しいパブリックキーを使用していることを確認します。上記の例では、プライベートキー .ssh/my_private_key.pem をファイル権限 0777 とともに使用します。これにより、任意のユーザーがこのファイルの読み取りまたは書き込みを行うことができます。この権限レベルの安全性は非常に低いので、SSH はこのキーを無視します。

MacOS または Linux から接続する場合、エラーを修正するには次のコマンドを実行し、プライベートキーファイルのパスを置き換えます。

[ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem

Windows から接続する場合は、ローカルコンピュータに対して次の手順を実行します。

  1. .pem ファイルに移動します。

  2. .pem ファイルを右クリックし、[プロパティ] を選択します。

  3. [セキュリティ] タブを選択します。

  4. [詳細] を選択します。

  5. 自分がファイルの所有者であることを確認します。そうでない場合は、所有者を自分のユーザー名に変更します。

  6. [継承の無効化] および [このオブジェクトから継承されたすべてのアクセス許可を削除] を選択します。

  7. [追加]、[プリンシパルの選択] を選択し、ユーザー名を入力して、[OK] をクリックします。

  8. [許可エントリ] ウィンドウから、読み取りアクセス許可を付与して、[OK] をクリックします。

  9. [Apply] (適用) をクリックして、すべての設定が保存されているようにします。

  10. [OK] をクリックして、[セキュリティの詳細設定] ウィンドウを閉じます。

  11. [OK] をクリックして、[プロパティ] ウィンドウを閉じます。

  12. Windows から SSH 経由で Linux インスタンスに接続できるはずです。

Windows のコマンドプロンプトから次のコマンドを実行します。

  1. コマンドプロンプトから、.pem ファイルのファイルパスの場所に移動します。

  2. 明示的なアクセス許可をリセットおよび削除するには、次のコマンドを実行します。

    icacls.exe $path /reset

  3. 現在のユーザーに読み取りアクセス許可を付与するには、次のコマンドを実行します。

    icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"

  4. 継承を無効にし、継承されたアクセス許可を削除するには、次のコマンドを実行します。

    icacls.exe $path /inheritance:r

  5. Windows から SSH 経由で Linux インスタンスに接続できるはずです。

エラー: プライベートキーの先頭は「-----BEGIN RSA PRIVATE KEY-----」、末尾は「-----END RSA PRIVATE KEY-----」にする必要があります

サードパーティーツール (例: ssh-keygen) を使用して RSA キーペアを作成すると、プライベートキーが OpenSSH キー形式で生成されます。インスタンスに接続する際、OpenSSH 形式のプライベートキーを使用してパスワードを復号すると、エラー (Private key must begin with "-----BEGIN RSA PRIVATE KEY-----" and end with "-----END RSA PRIVATE KEY-----") が発生する場合があります。

エラーを解消するには、プライベートキーは PEM 形式である必要があります。PEM 形式でプライベートキーを作成するには、次のコマンドを使用します。

ssh-keygen -m PEM

エラー: Server refused our key または No supported authentication methods available (サーバーはキーを拒否しましたまたは利用可能なサポートされる認証方法はありません)

PuTTY を使用してインスタンスに接続し、[Error: Server refused our key] または [Error: No supported authentication methods available] エラーが発生した場合は、AMI の適切なユーザー名で接続していることを確認します。[PuTTY 設定] ウィンドウの [ユーザー名] にユーザー名を入力します。

適切なユーザー名は以下のとおりです。

インスタンスの起動に使用される AMI デフォルトユーザー名

Amazon Linux 2022

Amazon Linux 2

Amazon Linux

 ec2-user
CentOS centos または ec2-user
Debian admin
Fedora fedora、または ec2-user
RHEL ec2-user、または root
SUSE ec2-user、または root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
その他 AMI プロバイダーに確認してください。

次の点も確認する必要があります。

インスタンスに対して ping を実行できない

ping コマンドは、ICMP トラフィックの一種です。インスタンスに対して Ping を実行できない場合は、インバウンドセキュリティグループのルールで、すべてのソースからの、あるいはコマンドを発行しているコンピュータまたはインスタンスからの Echo Request メッセージについて、ICMP トラフィックが許可されていることを確認します。

インスタンスから ping コマンドを発行できない場合は、アウトバウンドセキュリティグループのルールで、すべての宛先への、または Ping の対象であるホストへの Echo Request メッセージについて、ICMP トラフィックが許可されていることを確認します。

Ping コマンドは、ファイアウォールによってブロックされたり、ネットワークのレイテンシーやハードウェアの問題によってタイムアウトしたりすることもあります。詳しいトラブルシューティングについては、ローカルネットワークまたはシステム管理者に問い合わせてください。

エラー: サーバーによる予期しないネットワーク接続の閉鎖

PuTTY を使用してインスタンスに接続中に「サーバーによる予期しないネットワーク接続の閉鎖」エラーを受け取った場合、PuTTY 設定の接続ページでキープアライブを有効化して、切断を回避していることを確認してください。一部のサーバーは、指定された時間内にデータが一切受信されない場合に、クライアントを切断します。キープアライブ間の秒数を 59 秒に設定します。

キープアライブを有効後にも問題が依然として発生する場合には、PuTTY 設定の接続ページで Nagle のアルゴリズムを無効にすることを試してください。

エラー: EC2 Instance Connect のホストキーの検証に失敗しました

インスタンスホストキーをローテーションしても、新しいホストキーは AWS の信頼されたホストキーデータベースに自動的にアップロードされません。これにより、EC2 Instance Connect ブラウザベースのクライアントを使用してインスタンスに接続しようとすると、ホストキーの検証が失敗し、インスタンスに接続できなくなります。

エラーを解決するには、eic_harvest_hostkeys スクリプトをインスタンスで実行する必要があります。これにより、新しいホストキーが EC2 Instance Connect にアップロードされます。スクリプトは Amazon Linux 2 インスタンス上の /opt/aws/bin/ にあり、Ubuntu インスタンスでは /usr/share/ec2-instance-connect/ にあります。

Amazon Linux 2
Amazon Linux 2 インスタンスでホストキーの検証に失敗したエラーを解決するには

  1. SSH を使用してインスタンスに接続します。

    EC2 Instance Connect CLI を使用するか、インスタンスの起動時にインスタンスに割り当てた SSH キーペアと、インスタンスの起動に使用した AMI のデフォルトユーザー名を使用して接続できます。Amazon Linux 2 の場合、デフォルトのユーザー名は ec2-user です。

    例えば、Amazon Linux 2 を使用してインスタンスを起動した場合、インスタンスのパブリック DNS 名は ec2-a-b-c-d.us-west-2.compute.amazonaws.com、キーペアは my_ec2_private_key.pem です。次のコマンドを使用して SSH 経由でインスタンスに接続します。

    $ ssh -i my_ec2_private_key.pem ec2-user@ec2-a-b-c-d.us-west-2.compute.amazonaws.com

    インスタンスへの接続の詳細については、「SSH を使用した Linux インスタンスへの接続」を参照してください。

  2. 次のフォルダに移動します。

    [ec2-user ~]$ cd /opt/aws/bin/

  3. インスタンスで次のコマンドを実行します。


    [ec2-user ~]$ ./eic_harvest_hostkeys

    呼び出しが成功しても、出力されないことに注意してください。

    これで、EC2 Instance Connect ブラウザベースのクライアントを使用してインスタンスに接続できます。

Ubuntu
Ubuntuインスタンスでホストキーの検証に失敗したエラーを解決するには

  1. SSH を使用してインスタンスに接続します。

    EC2 Instance Connect CLI を使用するか、インスタンスの起動時にインスタンスに割り当てた SSH キーペアと、インスタンスの起動に使用した AMI のデフォルトユーザー名を使用して接続できます。Ubuntu の場合は、デフォルトのユーザー名は ubuntu です。

    例えば、Ubuntu を使用してインスタンスを起動した場合、インスタンスのパブリック DNS 名は ec2-a-b-c-d.us-west-2.compute.amazonaws.com、キーペアは my_ec2_private_key.pem です。次のコマンドを使用して SSH 経由でインスタンスに接続します。

    $ ssh -i my_ec2_private_key.pem ubuntu@ec2-a-b-c-d.us-west-2.compute.amazonaws.com

    インスタンスへの接続の詳細については、「SSH を使用した Linux インスタンスへの接続」を参照してください。

  2. 次のフォルダに移動します。

    [ec2-user ~]$ cd /usr/share/ec2-instance-connect/

  3. インスタンスで次のコマンドを実行します。


    [ec2-user ~]$ ./eic_harvest_hostkeys

    呼び出しが成功しても、出力されないことに注意してください。

    これで、EC2 Instance Connect ブラウザベースのクライアントを使用してインスタンスに接続できます。

EC2 Instance·Connect を使用して Unbntu インスタンスに接続できない

EC2 Instance Connect を使用して Ubuntu インスタンスへの接続を試行中にエラーが発生した場合、次の情報を使用して問題の解決を試みることができます。

考えられる原因

インスタンス上のec2-instance-connectパッケージは最新バージョンではありません。

解決策

次のように、インスタンス上のec2-instance-connectパッケージを最新バージョンにアップデートします。

  1. EC2 Instance Connect 以外の方法でインスタンスに接続します。

  2. インスタンス上で次のコマンドを実行してec2-instance-connectパッケージを最新バージョンにアップデートします。

    apt update && apt upgrade

プライベートキーを紛失しました。Linux インスタンスに接続するにはどうすればよいですか?

EBS-Backed インスタンスのプライベートキーを失った場合は、インスタンスへのアクセス権を回復することができます。インスタンスを停止し、そのルートボリュームをデタッチし、データボリュームとして別のインスタンスにアタッチし、新しいパブリックキーで authorized_keys ファイルを変更して、ボリュームを元のインスタンスに戻し、インスタンスを再起動する必要があります。インスタンスの起動、接続、および停止の詳細については、「インスタンスのライフサイクル」を参照してください。

この手順は、EBS ルートボリュームを持つインスタンスでのみサポートされます。ルートデバイスがインスタンスストアボリュームの場合、この手順を使用してインスタンスへのアクセスを回復することはできません。インスタンスに接続するには、プライベートキーが必要です。インスタンスのルートデバイスタイプを特定するには、Amazon EC2 コンソールを開き、[インスタンス] を選択します。インスタンスを選択後、[ストレージ] タブ (新しいコンソール) または [説明] タブ (古いコンソール) を選択してから、[ルートデバイスの詳細] セクションで [ルートデバイスタイプ] の値を確認します。

この値は EBS または INSTANCE-STORE のどちらかです。

プライベートキーを紛失した場合、以下の手順以外にも Linux インスタンスに接続する方法があります。詳細については、「最初の起動後に SSH キーペアを紛失した場合、Amazon EC2 インスタンスに接続するにはどうすればよいですか?」を参照してください。

ステップ 1: 新しいキーペアを作成する

Amazon EC2 コンソールまたはサードパーティ製のツールで、新しいキーペアを作成します。新しいキーペアの名前として、紛失したプライベートキーと同じ名前を指定するには、まず既存のキーペアを削除する必要があります。新しいキーペアの作成の詳細については、「Amazon EC2 を使用してキーペアを作成する」または「サードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートする」を参照してください。

ステップ 2: 元のインスタンスとそのルートボリュームに関する情報を取得する

この手順を完了するために必要になるので、次の情報を書き留めます。

元のインスタンスに関する情報を取得するには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで [Instances] を選択し、接続先にするインスタンスを選択します (このインスタンスを元のインスタンスと呼びます)。

  3. [Details] タブで、インスタンス ID と AMI ID を書き留めます。

  4. [Networking] タブで、アベイラビリティーゾーンを書き留めます。

  5. [Storage] タブの [Root device name] で、ルートボリュームのデバイス名 (/dev/xvda など) を書き留めます。次に、[Block devices] で、このデバイス名を見つけ、ボリューム ID (vol-0a1234b5678c910de など) を書き留めます。

ステップ 3: 元のインスタンスを停止する

[Instance state (インスタンスの状態)]、[Stop instance (インスタンスの停止)] の順に選択します。このオプションが無効になっている場合は、インスタンスが既に停止しているか、またはルートボリュームがインスタンスストアボリュームです。

警告

インスタンスを停止すると、インスタンスストアボリューム上のデータは消去されます。インスタンスストアボリュームのデータを保持するには、データを永続的ストレージに必ずバックアップします。

ステップ 4: 一時インスタンスを起動する

New console
一時インスタンスを起動するには

  1. ナビゲーションペインで [Instances] (インスタンス)、[Launch instances] (インスタンスの起動) の順に選択します。

  2. [Name and tags] (名前とタグ) セクションの [Name] (名前) に「Temporary (一時)」と入力します。

  3. [Application and OS Images] (アプリケーションと OS イメージ) セクションで、元のインスタンスの起動に使用したものと同じ AMI を選択します。その AMI を使用できない場合は、停止したインスタンスから使用可能な AMI を作成できます。詳細については、「Amazon EBS-backed Linux AMI を作成する」、「」を参照してください。

  4. [Instance type] (インスタンスタイプ) セクションでは、デフォルトのインスタンスタイプを保持します。

  5. [Key pair] (キーペア) セクションの [Key pair name] (キーペア名) で、使用する既存のキーペアを選択するか、新しいキーペアを作成します。

  6. [Network settings] (ネットワーク設定) セクションで [Edit] (編集) を選択し、次に [Subnet] (サブネット) で、元のインスタンスと同じアベイラビリティーゾーンのサブネットを選択します。

  7. [Summary] (サマリー) パネルで、[Launch] (起動) を選択します。

Old console

[Launch instances] を選択し、launch wizardを使用して、以下のオプションで一時インスタンスを起動します。

  • [Choose an AMI] ページで、元のインスタンスを起動するのに使用したのと同じ AMI を選択します。その AMI を使用できない場合は、停止したインスタンスから使用可能な AMI を作成できます。詳細については、「Amazon EBS-backed Linux AMI を作成する」を参照してください。

  • [Choose an Instance Type] ページで、ウィザードによって自動的に選択されたデフォルトのインスタンスタイプをそのままにします。

  • [Configure Instance Details] ページで、元のインスタンスと同じアベイラビリティーゾーンを指定します。VPC のインスタンスを起動する場合、このアベイラビリティーゾーンのサブネットを選択します。

  • [Add Tags] ページで、一時インスタンスであることを示すために、インスタンスに Name=Temporary タグを追加します。

  • [Review] ページで、[Launch] を選択します。ステップ 1 で作成したキーペアを選択し、「インスタンスの起動」を選択します。

ステップ 5: 元のインスタンスからルートボリュームをデタッチし、一時インスタンスにアタッチする

  1. ナビゲーションペインで [Volumes] を選択し、元のインスタンスのルートデバイスボリュームを選択します (前のステップでそのボリューム ID を書き留めました)。[Actions] (アクション)、[Detach Volume] (ボリュームのデタッチ)、[Detach] (デタッチする) の順に選択します。ボリュームの状態が available になるまで待ちます ([Refresh] アイコンを選択しなければならない場合があります)。

  2. ボリュームを選択したまま [Actions] (アクション) を選択し、次に [Attach Volume] (ボリュームをアタッチ) を選択します。一時インスタンスのインスタンス ID を選択し、[Device name] (デバイス名) で指定されたデバイス名 (例: /dev/sdf) を書き留めて、[Attach volume] (ボリュームをアタッチ) を選択します。

    注記

    元のインスタンスを AWS Marketplace AMI から起動して、ボリュームに AWS Marketplace のコードが含まれている場合は、ボリュームをアタッチする前に一時インスタンスを停止する必要があります。

ステップ 6: 一時インスタンスにマウントされた元のボリュームの authorized_keys に、新しいパブリックキーを追加する

  1. 一時インスタンスに接続します。

  2. 一時インスタンスから、そのファイルシステムにアクセスできるように、インスタンスにアタッチしたボリュームをマウントします。例えば、デバイス名が /dev/sdf の場合、次のコマンドを使用してボリュームを /mnt/tempvol としてマウントします。

    注記

    デバイス名の表示がインスタンスでは異なる場合があります。例えば、/dev/sdf としてマウントされているデバイスが、インスタンスでは /dev/xvdf として表示される場合があります。Red Hat の一部のバージョン (または CentOS などのバリアント) では、さらに末尾の文字が 4 文字インクリメントされる場合があります。例えば、/dev/sdf は /dev/xvdk になります。

    1. lsblkコマンドを使用して、ボリュームがパーティション分割されているかどうかを判断します。

      [ec2-user ~]$ 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  101G  0 disk
└─xvdf1 202:81   0  101G  0 part
xvdg    202:96   0   30G  0 disk

      前述の例では、/dev/xvda と /dev/xvdf は、パーティション分割されたボリュームで、/dev/xvdg はパーティション分割されていません。ボリュームがパーティション分割されている場合は、次のステップで raw デバイス (/dev/xvdf1)) の代わりにパーティション(/dev/xvdf) をマウントします。

    2. ボリュームをマウントするための一時ディレクトリを作成します。

      [ec2-user ~]$ sudo mkdir /mnt/tempvol

    3. 以前に特定したデバイス名またはボリューム名を使用して、一時マウントポイントにボリューム (またはパーティション) をマウントします。必要なコマンドは、オペレーティングシステムのファイルシステムによって異なります。注意事項デバイス名の表示がインスタンスでは異なる場合があります。詳細については、ステップ 6 の「note」を参照してください。

      • Amazon Linux、Ubuntu、Debian

        [ec2-user ~]$ sudo mount /dev/xvdf1 /mnt/tempvol

      • Amazon Linux 2、CentOS、SUSE Linux 12、RHEL 7.x

        [ec2-user ~]$ sudo mount -o nouuid /dev/xvdf1 /mnt/tempvol
    注記

    ファイルシステムが破損していることを示すエラーが表示された場合は、次のコマンドを実行して fsck ユーティリティを使用してファイルシステムをチェックし、問題を修復します。

    [ec2-user ~]$ sudo fsck /dev/xvdf1

  3. 一時インスタンスから、次のコマンドを使用して、一時インスタンスの authorized_keys からの新しいパブリックキーを使用し、マウントされたボリューム上で authorized_keys を更新します。

    重要

    以下の例では、Amazon Linux ユーザー名 ec2-user を使用します。Ubuntu インスタンスの場合は ubuntu など、別のユーザー名への置き換えが必要になる場合があります。

    [ec2-user ~]$ cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys

    このコピーが正常に終了すると、次のステップに進むことができます。

    (オプション) または、/mnt/tempvol のファイルを編集するアクセス許可がない場合、sudo を使用してファイルを更新してから、ファイルに対するアクセス許可を確認して、元のインスタンスにログインできるかどうかを確認する必要があります。次のコマンドを使用して、ファイルに対するアクセス許可を確認します。

    [ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh
total 4
-rw------- 1 222 500 398 Sep 13 22:54 authorized_keys

    この出力例では、222 はユーザー ID、500 はグループ ID です。次に、sudo を使用して失敗したコピーコマンドを再実行します。

    [ec2-user ~]$ sudo cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys

    次のコマンドを再度実行して、アクセス許可が変更されているかどうかを判断します。

    [ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh

    ユーザー ID とグループ ID が変更されている場合は、次のコマンドを実行して復元します。

    [ec2-user ~]$ sudo chown 222:500 /mnt/tempvol/home/ec2-user/.ssh/authorized_keys

ステップ 7: 一時インスタンスから元のボリュームをアンマウントしてデタッチし、元のインスタンスに再アタッチする

  1. 一時インスタンスから、元のインスタンスに再アタッチできるように、アタッチしたボリュームをアンマウントします。例えば、/mnt/tempvol のボリュームをアンマウントするには、次のコマンドを使用します。

    [ec2-user ~]$ sudo umount /mnt/tempvol

  2. (前のステップでアンマウントした) 一時インスタンスからボリュームをデタッチする: Amazon EC2 コンソールのナビゲーションペインで [Volumes] (ボリューム) を選択し、(前のステップでボリューム ID を書き留めた) 元のインスタンスのルートデバイスボリュームを選択し、[Actions] (アクション)、[Detach Volume] (ボリュームのデタッチ) の順に選択します。次に、[Detach] (デタッチ) を選択します。ボリュームの状態が available になるまで待ちます ([Refresh] アイコンを選択しなければならない場合があります)。

  3. ボリュームを元のインスタンスに再アタッチする: ボリュームを選択した状態で、[Action] (アクション)、[Attach Volume] (ボリュームをアタッチ) の順に選択します。元のインスタンスのインスタンス ID を選択し、元のルートデバイスのアタッチメントについて先程の ステップ 2 で記録したデバイス名 (/dev/sda1 または /dev/xvda) を指定してから、[Attach Volume] (ボリュームをアタッチ) を選択します。

    重要

    元のアタッチと同じデバイス名を指定しない場合、元のインスタンスを起動することはできません。Amazon EC2 は、ルートデバイスボリュームが sda1 または /dev/xvda であることを想定しています。

ステップ 8: 新しいキーペアを使用して元のインスタンスに接続する

元のインスタンスを選択し、[Instance state (インスタンスの状態)]、[Start instance (インスタンスの開始)] の順に選択します。インスタンスが running 状態になったら、新しいキーペアのプライベートキーファイルを使用して、そのインスタンスに接続できます。

注記

新しいキーペアおよび対応するプライベートキーファイルの名前が元のキーペアの名前と異なる場合は、インスタンスに接続するときに新しいプライベートキーファイルの名前を必ず指定します。

ステップ 9: クリーンアップする

(オプション) 一時インスタンスをそれ以上使用しない場合は、終了できます。一時インスタンスを選択し、[Instance state (インスタンスの状態)]、[Terminate instance (インスタンスの終了)] の順に選択します。