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

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

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

接続の問題

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

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

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

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

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

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

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

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

インスタンスの起動に使用される AMI	デフォルトユーザー名
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`
Rocky Linux	`rocky`
その他	AMI プロバイダーに確認してください。

セキュリティグループルールでトラフィックが許可されていることを確認する

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

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

インスタンスを起動してから接続リクエストを受け入れる準備が整うまでに、数分かかる場合があります。インスタンスをチェックして、それが実行中であり、ステータスチェックに合格していることを確認します。

Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。
ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択してください。
以下について確認してください。
1. [インスタンスの状態] 列で、インスタンスの状態が running であることを確認します。
2. [ステータスチェック] 列で、インスタンスが 2 つのステータスチェックに合格したことを確認します。

接続の前提条件をすべて満たしていることを確認する

接続に必要な情報がすべて揃っていることを確認します。詳細についてはSSH を使用した Linux インスタンスへの接続を参照してください。

Linux または macOS X から接続する

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

Windows から接続する

ローカルコンピュータのオペレーティングシステムが Windows の場合、Linux インスタンスに接続するための固有の前提条件について以下を確認してください。

インスタンスが管理されたインスタンスかを確認します

管理されたインスタンスへのユーザー主導の接続は許可されません。インスタンスが管理されているかどうかを判断するにはインスタンスの 管理された フィールドを見つけます。値が正の場合、管理されたインスタンスです。詳細についてはAmazon EC2 マネージドインスタンスを参照してください。

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

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

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

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

Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。
ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択してください。
コンソールページの下部にある [セキュリティ] タブの [インバウンドルール] で、選択したインスタンスで有効なルールのリストを確認します。ローカルコンピュータからポート 22 (SSH) へのトラフィックを許可するルールがあることを確認します。

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

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

サブネットのルートテーブルを確認します。

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

Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。
ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択してください。
[ネットワーキング] タブで、VPC ID とサブネット ID の値を書き留めます。
Amazon VPC コンソールの https://console.aws.amazon.com/vpc/ を開いてください。
ナビゲーションペインで、[Internet Gateways] を選択してください。ご使用の VPC にアタッチされているインターネットゲートウェイがあることを確認します。または[インターネットゲートウェイの作成] を選択し、インターネットゲートウェイの名前を入力して [インターネットゲートウェイの作成] を選択してください。次に、作成したインターネットゲートウェイで、[アクション]、[VPC にアタッチ]、[VPC] の順に選択し、[インターネットゲートウェイのアタッチ] をクリックして VPC にアタッチします。
ナビゲーションペインで [Subnets] を選択し、サブネットを選択してください。
[ルートテーブル] タブで、送信先として 0.0.0.0/0、ターゲットとして VPC のインターネットゲートウェイが指定されたルートがあることを確認します。IPv6 アドレスを使用してインスタンスに接続する場合はインターネットゲートウェイを指しているすべての IPv6 トラフィック (::/0) 用のルートがあることを確認します。それ以外の場合は以下の作業を行います。
1. ルートテーブルの ID (rtb-xxxxxxxx) を選択して、ルートテーブルに移動します。
2. [ルーター] タブで、[ルーター編集] を選択してください。[ルーター追加] を選択して、0.0.0.0/0 を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。IPv6 の場合は[ルーター追加] を選択して、::/0 を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。
3. [ルーター保存] を選択してください。

サブネットのネットワークアクセスコントロールリスト (ACL) を確認します。

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

Amazon VPC コンソールの https://console.aws.amazon.com/vpc/ を開いてください。
ナビゲーションペインで、[サブネット] を選択してください。
サブネットを選択する
[ネットワーク ACL] タブの [インバウンドルール] で、必要なポートでコンピュータからのインバウンドトラフィックを許可しているルールがあることを確認します。それが見つからない場合はコンピュータへのトラフィックをブロックしているルールを削除または変更します。
[アウトバウンドルール] で、一時ポートでコンピュータへのトラフィックを許可しているルールがあることを確認します。存在しない場合はコンピュータへのトラフィックをブロックしているルールを削除または変更します。

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

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

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

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

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

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

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

負荷が変化する場合、Auto Scaling およびエラスティックロードバランシングを使用して、インスタンスの増減を自動的に縮小・拡張できます。
負荷が常に増加している場合、大きなインスタンスタイプに移動できます。詳細についてはAmazon EC2 インスタンスタイプの変更を参照してください。

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

サブネットはインターネットゲートウェイへの IPv6 トラフィック (::/0) のルートを持つルートテーブルに関連付けられている必要があります。
セキュリティグループルールではポート 22 でローカル IPv6 アドレスからのインバウンドトラフィックを許可する必要があります。
ネットワーク ACL ルールではインバウンドおよびアウトバウンドの IPv6 トラフィックを許可する必要があります。
古い AMI からインスタンスを起動した場合、DHCPv6 用に設定されていない可能性があります (IPv6 アドレスはネットワークインターフェイスでは自動的に認識されません)。詳細については「Amazon VPC ユーザーガイド」の「インスタンスに IPv6 を設定する」を参照してください。
ローカルコンピュータに IPv6 アドレスがあり、IPv6 を使用するように設定されている必要があります。

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

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

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

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

注記
サードパーティー製のツールを使用して、新しいキーペアを作成することもできます。詳細についてはサードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートするを参照してください。
新しいキーペアをインスタンスに追加します。詳細についてはプライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?を参照してください。
新しいキーペアを使用してインスタンスに接続します。

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

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 を使用して Linux インスタンスに接続するを参照してください。

注記
PuTTYgen でプライベートキーファイルをロードし、[Generate] ではなく [Save Private キー] を選択してください。

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

インスタンスの起動に使用される AMI	デフォルトユーザー名
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`
Rocky Linux	`rocky`
その他	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	`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`
Rocky Linux	`rocky`
その他	AMI プロバイダーに確認してください。

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


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

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

Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。
ナビゲーションペインで [インスタンス] を選択し、インスタンスを選択してください。
[詳細] タブの [インスタンスの詳細] で、[キーペア名] の値を確認します。
インスタンスを起動したときにキーペアを指定しなかった場合はキーペアを確実に指定するために、インスタンスを終了してから新しいインスタンスを起動します。それまで使用していたインスタンスで、キーペアに対する .pem ファイルがもう存在しない場合はそのキーペアを新しいキーペアで置き換えることができます。詳細についてはプライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?を参照してください。

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

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

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

インスタンスを停止し、ルートボリュームをデタッチします。詳細についてはAmazon EC2 インスタンスの停止と起動を参照してください。
同じアベイラビリティーゾーンにある一時インスタンスを現在のインスタンスとして起動し (現在のインスタンスに使用したのと同様または同じ AMI を使用)、ルートボリュームを一時インスタンスにアタッチします。
一時インスタンスに接続してマウントポイントを作成し、アタッチしたボリュームをマウントします。
一時インスタンスから、アタッチされたボリュームの /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
```
ボリュームをアンマウントして一時インスタンスからデタッチし、元のインスタンスに再アタッチします。ルートボリュームに適切なデバイス名を指定したことを確認します (/dev/xvda など)。
インスタンスを起動します。一時インスタンスが必要なくなった場合は終了できます。

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

プライベートキーファイルはその他のすべてのユーザーの読み取りおよび書き込み操作から保護されている必要があります。プライベートキーがお客様以外のユーザーによって読み取りまたは書き込みできる場合、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 から Linux インスタンスに接続する場合はローカルコンピュータに対して次の手順を実行します。

.pem ファイルに移動します。
.pem ファイルを右クリックし、[プロパティ] を選択してください。
[セキュリティ] タブを選択してください。
[詳細] を選択してください。
自分がファイルの所有者であることを確認します。そうでない場合は所有者を自分のユーザー名に変更します。
[継承の無効化] および [このオブジェクトから継承されたすべてのアクセス許可を削除] を選択してください。
[追加]、[プリンシパルの選択] を選択し、ユーザー名を入力して、[OK] をクリックしてください。
[許可エントリ] ウィンドウから、読み取りアクセス許可を付与して、[OK] をクリックしてください。
[Apply] (適用) をクリックして、すべての設定が保存されているようにします。
[OK] をクリックして、[セキュリティの詳細設定] ウィンドウを閉じます。
[OK] をクリックして、[プロパティ] ウィンドウを閉じます。
Windows から SSH を使用して Linux インスタンスに接続できるはずです。

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

コマンドプロンプトから、.pem ファイルのファイルパスの場所に移動します。
明示的なアクセス許可をリセットおよび削除するには次のコマンドを実行します。
```
icacls.exe $path /reset
```
現在のユーザーに読み取りアクセス許可を付与するには次のコマンドを実行します。
```
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
```
継承を無効にし、継承されたアクセス許可を削除するには次のコマンドを実行します。
```
icacls.exe $path /inheritance:r
```
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

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

このエラーは、 known_hosts ファイル内のインスタンスに保存されているホストキーとクライアントに保存されているホストキーが一致しない場合に発生します。例えば、あるパブリック IP アドレスを使用してインスタンスに接続し、別のパブリック IP アドレスを使用して再度接続しようとすると、不一致が発生する可能性があります。これは、Elastic IP アドレスを追加または削除した後に発生する可能性があります。理由は、インスタンスのパブリック IP アドレスが変更されるためです。

このエラーを解決するには、まず、インスタンスのホストキーまたはネットワーク設定に予期された変更があったことを確認します。インスタンスに接続する前に、ホストフィンガープリントを確認することもお勧めします。インスタンスに接続したら、 known_hosts ファイルから古いホストキーを削除できます。手順については、インスタンスで使用されている Linux ディストリビューションのドキュメントを参照してください。

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

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

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

インスタンスの起動に使用される AMI	デフォルトユーザー名
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`
Rocky Linux	`rocky`
その他	AMI プロバイダーに確認してください。

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

最新バージョンの PuTTY を使用している。詳細についてはPuTTY のウェブページを参照してください。
プライベートキー (.pem) ファイルが PuTTY によって認識される形式 (.ppk) に正しく変換されている。プライベートキーの変換の詳細についてはPuTTY を使用して Linux インスタンスに接続するを参照してください。

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

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

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

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

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

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

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

エラー: EC2 インスタントコネクトのホストキーの検証に失敗しました

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

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

Amazon Linux 2

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

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

EC2 インスタントコネクト 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 インスタンスに接続するを参照してください。
次のフォルダに移動します。
```
[ec2-user ~]$ cd /opt/aws/bin/
```
インスタンスで次のコマンドを実行します。 
```
[ec2-user ~]$ ./eic_harvest_hostkeys
```
呼び出しが成功しても、出力されないことに注意してください。

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

Ubuntu

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

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

EC2 インスタントコネクト 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 インスタンスに接続するを参照してください。

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


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

インスタンスで次のコマンドを実行します。 
```
[ec2-user ~]$ ./eic_harvest_hostkeys
```
呼び出しが成功しても、出力されないことに注意してください。

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

EC2 インスタントコネクトを使用して Unbntu インスタンスに接続できない

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

考えられる原因

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

解決策

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

EC2 インスタントコネクト以外の方法でインスタンスに接続します。
インスタンス上で次のコマンドを実行してec2-instance-connectパッケージを最新バージョンにアップデートします。
```
apt update && apt upgrade
```

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

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

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

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

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

別のキーペアを使用して EBS-Backed インスタンスに接続するためのステップ

ステップ 1: 新しいキーペアを作成する
ステップ 2: 元のインスタンスとそのルートボリュームに関する情報を取得する
ステップ 3: 元のインスタンスを停止する
ステップ 4: 一時インスタンスを起動する
ステップ 5: 元のインスタンスからルートボリュームをデタッチし、一時インスタンスにアタッチする
ステップ 6: 一時インスタンスにマウントされた元のボリュームの authorized_keys に、新しいパブリックキーを追加する
ステップ 7: 一時インスタンスから元のボリュームをアンマウントしてデタッチし、元のインスタンスに再アタッチする
ステップ 8: 新しいキーペアを使用して元のインスタンスに接続する
ステップ 9: クリーンアップする

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

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

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

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

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

Amazon EC2 コンソールの https://console.aws.amazon.com/ec2/ を開いてください。
ナビゲーションペインで [Instances] を選択し、接続先にするインスタンスを選択します (このインスタンスを元のインスタンスと呼びます)。
[Details] タブで、インスタンス ID と AMI ID を書き留めます。
[ネットワーキング] タブで、アベイラビリティーゾーンを書き留めます。
[Storage] タブの [ルートデバイス名] で、ルートボリュームのデバイス名 (/dev/xvda など) を書き留めます。次に、[Block devices] で、このデバイス名を見つけ、ボリューム ID (vol-0a1234b5678c910de など) を書き留めます。

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

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

警告

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

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

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

ナビゲーションペインで [Instances] (インスタンス)、[Launch instances] (インスタンスの起動) の順に選択してください。
[Name and tags] (名前とタグ) セクションの [Name] (名前) に「Temporary (一時)」と入力してください。
[Application and OS Images] (アプリケーションと OS イメージ) セクションで、元のインスタンスの起動に使用したものと同じ AMI を選択してください。その AMI を使用できない場合は停止したインスタンスから使用可能な AMI を作成できます。詳細についてはAmazon EBS-backed AMI を作成するを参照してください。
[Instance type] (インスタンスタイプ) セクションではデフォルトのインスタンスタイプを保持します。
[キー pair] (キーペア) セクションの [キー pair name] (キーペア名) で、使用する既存のキーペアを選択するか、新しいキーペアを作成します。
[ネットワーク設定] セクションで [編集] を選択し、次に [サブネット] で、元のインスタンスと同じアベイラビリティーゾーンのサブネットを選択してください。
[Summary] (サマリー) パネルで、[Launch] (起動) を選択してください。

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

ナビゲーションペインで [Volumes] を選択し、元のインスタンスのルートデバイスボリュームを選択します (前のステップでそのボリューム ID を書き留めました)。[アクションs] (アクション)、[Detach Volume] (ボリュームのデタッチ)、[Detach] (デタッチする) の順に選択してください。ボリュームの状態が available になるまで待ちます ([Refresh] アイコンを選択しなければならない場合があります)。
ボリュームを選択したまま [アクションs] (アクション) を選択し、次に [Attach Volume] (ボリュームをアタッチ) を選択してください。一時インスタンスのインスタンス ID を選択し、[Device name] (デバイス名) で指定されたデバイス名 (例: /dev/sdf) を書き留めて、[Attach volume] (ボリュームをアタッチ) を選択してください。

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

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

一時インスタンスに接続します。
一時インスタンスから、そのファイルシステムにアクセスできるように、インスタンスにアタッチしたボリュームをマウントします。例えば、デバイス名が /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
```
一時インスタンスから、次のコマンドを使用して、一時インスタンスの 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: 一時インスタンスから元のボリュームをアンマウントしてデタッチし、元のインスタンスに再アタッチする

一時インスタンスから、元のインスタンスに再アタッチできるように、アタッチしたボリュームをアンマウントします。例えば、/mnt/tempvol のボリュームをアンマウントするには次のコマンドを使用します。
```
[ec2-user ~]$ sudo umount /mnt/tempvol
```
(前のステップでアンマウントした) 一時インスタンスからボリュームをデタッチする: Amazon EC2 コンソールのナビゲーションペインで [Volumes] (ボリューム) を選択し、(前のステップでボリューム ID を書き留めた) 元のインスタンスのルートデバイスボリュームを選択し、[アクションs] (アクション)、[Detach Volume] (ボリュームのデタッチ) の順に選択してください。次に、[Detach] (デタッチ) を選択してください。ボリュームの状態が available になるまで待ちます ([Refresh] アイコンを選択しなければならない場合があります)。
ボリュームを元のインスタンスに再アタッチする: ボリュームを選択した状態で、[アクション] (アクション)、[Attach Volume] (ボリュームをアタッチ) の順に選択してください。元のインスタンスのインスタンス ID を選択し、元のルートデバイスのアタッチメントについて先程のステップ 2 で記録したデバイス名 (/dev/sda1 または /dev/xvda) を指定してから、[Attach Volume] (ボリュームをアタッチ) を選択してください。

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

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

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

注記

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

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

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

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Windows インスタンスの一般的なスクリーンショット

Linux インスタンスのステータスチェックの失敗