コンソールにサインインする
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

AWS ドキュメント » Amazon EC2 » Linux インスタンス用ユーザーガイド » インスタンスのトラブルシューティング » インスタンスへの接続に関するトラブルシューティング

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

以下では、発生する可能性のある問題、およびインスタンスへの接続時に表示される可能性のあるメッセージを示します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    4. https://console.aws.amazon.com/vpc/にある Amazon 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 アドレスからのインバウンドおよびアウトバウンドトラフィックを許可する必要があります。デフォルトのネットワーク ACL では、すべてのインバウンドトラフィックとアウトバウンドトラフィックを許可します。

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

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

    3. [Description (説明)] タブで、[ネットワーク ACL] を探し、その ID (acl-xxxxxxxx) を選択します。

    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 を使用するように設定されている必要があります。

エラー: キーをロードできません ... Expecting: ANY PRIVATE KEY

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

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

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

  2. 新しいキーペアをインスタンスに追加します。詳細については、「プライベートキーを紛失した場合の Linux インスタンスへの接続」を参照してください。

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

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

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

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

    ssh -vvv -i [your key name].pem ec2-user@[public DNS address of your instance].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] ボックスにユーザー名を入力します。

    • Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は ec2-user です。

    • CentOS AMI の場合、ユーザー名は centos です。

    • Debian AMI の場合は、ユーザー名は admin または root です。

    • Fedora AMI の場合、ユーザー名は ec2-user または fedora です。

    • RHEL AMI の場合は、ユーザー名は ec2-user または root のどちらかです。

    • SUSE AMI の場合は、ユーザー名は ec2-user または root のどちらかです。

    • Ubuntu AMI の場合は、ユーザー名は ubuntu です。

    • それ以外の場合で、ec2-user および root が機能しない場合は、AMI プロバイダーに確認してください。

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

エラー: Host key not found、Permission denied (publickey)、または Authentication failed, permission denied (ホストキーが見つかりません、権限の拒否 (publickey)、または認証失敗、権限の拒否)

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

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

  • Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は ec2-user です。

  • CentOS AMI の場合、ユーザー名は centos です。

  • Debian AMI の場合は、ユーザー名は admin または root です。

  • Fedora AMI の場合、ユーザー名は ec2-user または fedora です。

  • RHEL AMI の場合は、ユーザー名は ec2-user または root のどちらかです。

  • SUSE AMI の場合は、ユーザー名は ec2-user または root のどちらかです。

  • Ubuntu AMI の場合は、ユーザー名は ubuntu です。

  • それ以外の場合で、ec2-user および root が機能しない場合は、AMI プロバイダーに確認してください。

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

ssh -i /path/my-key-pair.pem ec2-user@public-dns-hostname

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

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

  2. インスタンスを選択します。[Description] タブで、[Key pair name] の値を確認します。

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

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

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

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

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

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

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

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

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

  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 はこのキーを無視します。エラーを修正するには、次のコマンドを実行し、プライベートキーファイルのパスを置き換えます。 

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

エラー: プライベートキーの先頭は「-----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 設定] ウィンドウの [ユーザー名] にユーザー名を入力します。

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

  • Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は ec2-user です。

  • CentOS AMI の場合、ユーザー名は centos です。

  • Debian AMI の場合は、ユーザー名は admin または root です。

  • Fedora AMI の場合、ユーザー名は ec2-user または fedora です。

  • RHEL AMI の場合は、ユーザー名は ec2-user または root のどちらかです。

  • SUSE AMI の場合は、ユーザー名は ec2-user または root のどちらかです。

  • Ubuntu AMI の場合は、ユーザー名は ubuntu です。

  • それ以外の場合で、ec2-user および root が機能しない場合は、AMI プロバイダーに確認してください。

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

ブラウザを使用して接続できない

Amazon EC2 コンソールには、Java SSH クライアントを使用してブラウザからインスタンスに直接接続するオプションがあります。ブラウザで NPAPI がサポートされていない場合は、接続すると Chrome での NPAPI の廃止エラーメッセージが表示されます。このメッセージは、別のブラウザを使用することを推奨しています。ただし、これらのブラウザの最新バージョンでも NPAPI をサポートしていないため、それらを使用してインスタンスに接続することはできません。別の方法を選択して、インスタンスに接続する必要があります。

詳細については、以下のリソースを参照してください。

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

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

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

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

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