インスタンスへの接続に関するトラブルシューティング
以下の情報は、インスタンスへの接続に関する問題のトラブルシューティングに役立ちます。Windows インスタンスの詳細なヘルプについては、Windows インスタンスの Amazon EC2 ユーザーガイド の「Windows インスタンスのトラブルシューティング」を参照してください。
接続の問題とエラー
- 接続の問題の一般的な原因
- インスタンスへの接続エラー: 接続タイムアウト
- エラー: キーを読み込めません...期待: 任意のプライベートキー
- エラー: ユーザーキーがサーバーによって認識されない
- エラー: アクセス許可が拒否されたか、[インスタンス] ポート 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 のホストキーの検証に失敗しました
接続の問題の一般的な原因
インスタンスへの接続に関する問題の一般的な原因を確認することにより、トラブルシューティングを開始することをお勧めします。
- インスタンスのユーザー名を確認する
-
インスタンスに接続するには、ユーザーアカウントのユーザー名、またはインスタンスの起動に使用した AMI のデフォルトのユーザー名を使用します。
-
ユーザーアカウントのユーザー名を取得します。
ユーザーアカウントの作成方法については、「Amazon Linux インスタンスでのユーザーアカウントの管理」を参照してください。
-
インスタンスの起動に使用した AMI のデフォルトのユーザー名を取得します。
-
Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は
ec2-userです。 -
CentOS AMI の場合、ユーザー名は
centosです。 -
Debian AMI の場合は、ユーザー名は
adminです。 -
Fedora AMI の場合、ユーザー名は
ec2-userまたはfedoraです。 -
RHEL AMI の場合は、ユーザー名は
ec2-userまたはrootのどちらかです。 -
SUSE AMI の場合は、ユーザー名は
ec2-userまたはrootのどちらかです。 -
Ubuntu AMI の場合は、ユーザー名は
ubuntuです。 -
それ以外の場合で、
ec2-userおよびrootが機能しない場合は、AMI プロバイダーに確認してください。
-
-
- セキュリティグループルールでトラフィックが許可されていることを確認する
-
セキュリティグループルールで、適切なポート上のパブリック IPv4 アドレスからのインバウンドトラフィックが許可されることを確認します。確認するステップについては、「インスタンスへの接続エラー: 接続タイムアウト」を参照してください。
- インスタンスが準備ができていることを確認する
-
インスタンスを起動してから接続できるようになるまでには、数分かかる場合があります。インスタンスをチェックして、それが実行中であり、ステータスチェックに合格していることを確認します。
-
https://console.aws.amazon.com/ec2/
で Amazon EC2 コンソールを開きます。 -
ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択します。
-
以下について確認してください。
-
[インスタンスの状態] 列で、インスタンスの状態が
runningであることを確認します。 -
[ステータスチェック] 列で、インスタンスが 2 つのステータスチェックに合格したことを確認します。
-
-
- インスタンスに接続するための一般的な前提条件を確認する
-
詳細については、「インスタンスに接続するための一般的な前提条件」を参照してください。
インスタンスへの接続エラー: 接続タイムアウト
インスタンスへ接続しようとして、エラーメッセージ Network error:
Connection timed out または Error connecting to [instance], reason: -> Connection
timed out: connect が表示される場合、次を実行します。
セキュリティグループルールを調べます。
適切なポートのパブリック IPv4 アドレスからのインバウンドトラフィックがセキュリティグループルールで許可されている必要があります。
サブネットのルートテーブルを確認します。
VPC の外部あてのすべてのトラフィックを VPC のインターネットゲートウェイに送信するには、ルートが必要です。
サブネットのネットワークアクセスコントロールリスト (ACL) を確認します。
ネットワーク ACL が適切なポートのローカル IP アドレスからのインバウンドおよびアウトバウンドトラフィックを許可する必要があります。デフォルトのネットワーク ACL では、すべてのインバウンドトラフィックとアウトバウンドトラフィックを許可します。
-
Amazon VPC コンソール (https://console.aws.amazon.com/vpc/
) を開きます。 -
ナビゲーションペインで [サブネット] を選択し、任意のサブネットを選択します。
-
[Description (説明)] タブで、[ネットワーク ACL] を探し、その ID (acl-xxxxxxxx) を選択します。
-
ネットワーク ACL を選択します。[インバウンドルール] で、コンピュータからのトラフィックがルールで許可されていることを確認します。そうでない場合、コンピュータからのトラフィックをブロックしているルールを削除または変更します。
-
[アウトバウンドルール] で、コンピュータへのトラフィックがルールで許可されていることを確認します。そうでない場合、コンピュータへのトラフィックをブロックしているルールを削除または変更します。
コンピュータが社内ネットワークに接続されている場合
社内ファイアウォールで、ご使用のコンピュータのインバウンドおよびアウトバウンドのトラフィックがポート 22 (Linux インスタンスの場合) またはポート 3389 (Windows インスタンスの場合) で許可されているかどうか、ネットワーク管理者に問い合わせてください。
ご使用のコンピュータにファイアウォールが設定されている場合、そのファイアウォールでコンピュータのインバウンドおよびアウトバウンドのトラフィックがポート 22 (Linux インスタンスの場合) またはポート 3389 (Windows インスタンスの場合) で許可されているかどうか確認します。
インスタンスにパブリック IPv4 アドレスがあることを確認します。
そうでない場合は、Elastic IP アドレスをインスタンスに関連付けることができます。詳細については、「Elastic IP アドレス」を参照してください。
サーバーが過負荷になっている可能性のあるインスタンスの CPU 負荷を確認します。
AWS は自動的に Amazon CloudWatch メトリクスおよびインスタンスステータスなどのデータを提供します。これを使用してインスタンスの CPU 負荷を確認でき、必要に応じて、負荷の処理方法を調整できます。詳細については、「CloudWatch を使用したインスタンスのモニタリング」を参照してください。
-
負荷が変化する場合、Auto Scaling
および Elastic Load Balancing を使用して、インスタンスの増減を自動的に縮小・拡張できます。 -
負荷が常に増加している場合、大きなインスタンスタイプに移動できます。詳細については、「インスタンスタイプを変更する」を参照してください。
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 を使用してキーペアを作成する」を参照してください。
-
新しいキーペアをインスタンスに追加します。詳細については、「プライベートキーを紛失した場合の Linux インスタンスへの接続」を参照してください。
-
新しいキーペアを使用してインスタンスに接続します。
エラー: ユーザーキーがサーバーによって認識されない
SSH を使用してインスタンスに接続している場合
-
ssh -vvvを使用して、接続中に 3 倍詳細デバッグ情報を取得します。ssh -vvv -ipath/my-key-pair.pemmy-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] ボックスにユーザー名を入力します。
-
Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は
ec2-userです。 -
CentOS AMI の場合、ユーザー名は
centosです。 -
Debian AMI の場合は、ユーザー名は
adminです。 -
Fedora AMI の場合、ユーザー名は
ec2-userまたはfedoraです。 -
RHEL AMI の場合は、ユーザー名は
ec2-userまたはrootのどちらかです。 -
SUSE AMI の場合は、ユーザー名は
ec2-userまたはrootのどちらかです。 -
Ubuntu AMI の場合は、ユーザー名は
ubuntuです。 -
それ以外の場合で、
ec2-userおよびrootが機能しない場合は、AMI プロバイダーに確認してください。
-
-
適切なポートへのインバウンドトラフィックを許可しているインバウンドセキュリティグループがあることを確認します。詳細については、「インスタンスへのネットワークアクセスの許可」を参照してください。
エラー: アクセス許可が拒否されたか、[インスタンス] ポート 22 によって接続が閉じられました。
SSH を使用してインスタンスに接続し、Host key not found in [directory]、Permission denied (publickey)、Authentication failed, permission denied、または Connection closed by [instance] port 22 のいずれかのエラーが発生した場合は、AMI 用の適切なユーザー名で接続しており、なおかつインスタンス用の適切なプライベートキー (.pem)) ファイルを指定していることを確認します。
適切なユーザー名は以下のとおりです。
-
Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は
ec2-userです。 -
CentOS AMI の場合、ユーザー名は
centosです。 -
Debian AMI の場合は、ユーザー名は
adminです。 -
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.pemmy-instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com
使用しているプライベートキーファイルが、インスタンスの起動時に選択したキーペアに対応していることを確認します。
独自のキーペアを生成した場合は、キージェネレータが RSA キーを作成するように設定されていることを確認します。DSA キーは受け入れられません。
Permission denied (publickey) エラーが表示され、上のいずれも当てはまらない場合 (たとえば、以前は接続できていたなど)、インスタンスのホームディレクトリのアクセス権限が変更された可能性があります。/home/ のアクセス権限は、所有者のみに制限する必要があります。
my-instance-user-name/.ssh/authorized_keys
インスタンスのアクセス権限を検証するには
-
インスタンスを停止し、ルートボリュームをデタッチします。詳細については、「インスタンスの停止と起動」および「Linux インスタンスからの Amazon EBS ボリュームのデタッチ」を参照してください。
-
同じアベイラビリティーゾーンにある一時インスタンスを現在のインスタンスとして起動し (現在のインスタンスに使用したのと同様または同じ AMI を使用)、ルートボリュームを一時インスタンスにアタッチします。詳細については、「インスタンスへの Amazon EBS ボリュームのアタッチ」を参照してください。
-
一時インスタンスに接続してマウントポイントを作成し、アタッチしたボリュームをマウントします。詳細については、「Linux で Amazon EBS ボリュームを使用できるようにする」を参照してください。
-
一時インスタンスから、アタッチされたボリュームの
/home/ディレクトリのアクセス権限をチェックします。必要に応じて、次のようにアクセス権限を調整します。my-instance-user-name/[ec2-user ~]$chmod 600mount_point/home/my-instance-user-name/.ssh/authorized_keys[ec2-user ~]$chmod 700mount_point/home/my-instance-user-name/.ssh[ec2-user ~]$chmod 700mount_point/home/my-instance-user-name -
ボリュームをアンマウントして一時インスタンスからデタッチし、元のインスタンスに再アタッチします。ルートボリュームに適切なデバイス名を指定したことを確認します (
/dev/xvdaなど)。 -
インスタンスを起動します。一時インスタンスが必要なくなった場合は、終了できます。
エラー: 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です。 -
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 インスタンスへの接続」を参照してください。
インスタンスに対して 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/ にあります。
