# Amazon EC2 Linux インスタンスへの接続に関する問題のトラブルシューティング
以下の情報と一般的なエラーはLinux インスタンスへの接続に関するトラブルシューティングに役立ちます。
**Topics**
+ [接続の問題の一般的な原因](#TroubleshootingInstancesCommonCauses)
+ [インスタンスへの接続エラー: 接続タイムアウト](#TroubleshootingInstancesConnectionTimeout)
+ [エラー: キーを読み込めません..。期待: 任意のプライベートキー](#troubleshoot-instance-connect-key-file)
+ [エラー: ユーザーキーがサーバーによって認識されない](#TroubleshootingInstancesServerError)
+ [エラー: アクセス許可が拒否されたか、[インスタンス] ポート 22 によって接続が閉じられました。](#TroubleshootingInstancesConnectingSSH)
+ [エラー: Unprotected Private キー ファイル (保護されていないプライベートキーファイル)](#troubleshoot-unprotected-key)
+ [エラー: プライベートキーの先頭は「-----BEGIN RSA PRIVATE KEY-----」、末尾は「-----END RSA PRIVATE KEY-----」にする必要があります](#troubleshoot-private-key-file-format)
+ [エラー: ホストキーの検証に失敗しました](#troubleshoot-host-key-verification-failed)
+ [エラー: サーバー refused our key *または* No supported authentication methods available (サーバーはキーを拒否しましたまたは利用可能なサポートされる認証方法はありません)](#TroubleshootingInstancesConnectingPuTTY)
+ [インスタンスに対して ping を実行できない](#troubleshoot-instance-ping)
+ [エラー: サーバーによる予期しないネットワーク接続の閉鎖](#troubleshoot-ssh)
+ [エラー: EC2 インスタントコネクト のホストキーの検証に失敗しました](#troubleshoot-host-key-validation)
+ [EC2 インスタントコネクト を使用して Unbntu インスタンスに接続できない](#troubleshoot-eic-ubuntu)
+ [プライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?](#replacing-lost-key-pair)
## 接続の問題の一般的な原因
次のタスクを正確に実行したことを確認して、インスタンス接続の問題のトラブルシューティングを開始することをお勧めします。
**インスタンスのユーザー名を確認する**
インスタンスに接続するにはユーザーアカウントのユーザー名、またはインスタンスの起動に使用した AMI のデフォルトのユーザー名を使用します。
+ **ユーザーアカウントのユーザー名を取得します。**
ユーザーアカウントの作成方法については[Amazon EC2 Linux インスタンスのシステムユーザーを管理する](managing-users.md)を参照してください。
+ **インスタンスの起動に使用した AMI のデフォルトのユーザー名を取得します。**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)
**セキュリティグループルールでトラフィックが許可されていることを確認する**
インスタンスに関連付けられているセキュリティグループで、IP アドレスからの受信 SSH トラフィックが許可されていることを確認します。VPC のデフォルトのセキュリティグループでは着信 SSH トラフィックはデフォルトでは許可されません。インスタンス起動ウィザードで作成されたセキュリティグループではデフォルトで SSH トラフィックが許可されます。Linux インスタンスにインバウンド SSH トラフィックのルールを追加する手順については[コンピュータからのインスタンスへの接続ルール](security-group-rules-reference.md#sg-rules-local-access)を参照してください。確認する手順については[インスタンスへの接続エラー: 接続タイムアウト](#TroubleshootingInstancesConnectionTimeout)を参照してください。
**インスタンスが準備ができていることを確認する**
インスタンスを起動してから接続リクエストを受け入れる準備が整うまでに、数分かかる場合があります。インスタンスをチェックして、それが実行中であり、ステータスチェックに合格していることを確認します。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで [**インスタンス**] を選択し、インスタンスを選択してください。
1. 以下について確認してください。
1. [**インスタンスの状態**] 列で、インスタンスの状態が `running` であることを確認します。
1. **[ステータスチェック]** 列で、インスタンスがすべてのステータスチェックに合格したことを確認します。
**接続の前提条件をすべて満たしていることを確認する**
接続に必要な情報がすべて揃っていることを確認します。詳細については、「[SSH を使用した Linux インスタンスへの接続](connect-to-linux-instance.md)」を参照してください。
**Linux または macOS X から接続する**
ローカルコンピュータのオペレーティングシステムが Linux または macOS X の場合、Linux インスタンスに接続するための固有の前提条件について以下を確認してください。
+ [SSH クライアント](connect-linux-inst-ssh.md)
+ [EC2 インスタントコネクト](connect-linux-inst-eic.md)
+ [AWS Systems Manager セッションマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
**Windows から接続する**
ローカルコンピュータのオペレーティングシステムが Windows の場合、Linux インスタンスに接続するための固有の前提条件について以下を確認してください。
+ [OpenSSH](connect-linux-inst-ssh.md)
+ [PuTTY](connect-linux-inst-from-windows.md)
+ [AWS Systems Manager セッションマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Windows Subsystem for Linux](connect-linux-inst-ssh.md)
**インスタンスが管理されたインスタンスかを確認します**
管理されたインスタンスへのユーザー主導の接続は許可されません。インスタンスが管理されているかどうかを判断するにはインスタンスの **管理された** フィールドを見つけます。値が **正** の場合、管理されたインスタンスです。詳細については、「[Amazon EC2 マネージドインスタンス](amazon-ec2-managed-instances.md)」を参照してください。
## インスタンスへの接続エラー: 接続タイムアウト
インスタンスへ接続しようとして、エラーメッセージ `Network error: Connection timed out` または `Error connecting to [instance], reason: -> Connection timed out: connect` が表示される場合、次を実行します。
**セキュリティグループルールを調べます。**
ローカルコンピュータの適切なポートのパブリック IPv4 アドレスからのインバウンドトラフィックがセキュリティグループルールで許可されている必要があります。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで [**インスタンス**] を選択し、インスタンスを選択してください。
1. コンソールページの下部にある [**セキュリティ**] タブの [**インバウンドルール**] で、選択したインスタンスで有効なルールのリストを確認します。ローカルコンピュータからポート 22 (SSH) へのトラフィックを許可するルールがあることを確認します。
セキュリティグループに、ローカルコンピュータからのインバウンドトラフィックを許可するルールがない場合はセキュリティグループにルールを追加します。詳細については、「[コンピュータからのインスタンスへの接続ルール](security-group-rules-reference.md#sg-rules-local-access)」を参照してください。
1. インバウンドトラフィックを許可するルールについては**[Source]** (ソース) フィールドを確認します。値が単一の IP アドレスで、IP アドレスが静的でない場合、コンピュータを再起動するたびに新しい IP アドレスが割り当てられます。これにより、ルールにはコンピュータの IP アドレストラフィックが含まれなくなります。コンピュータが企業ネットワークにある場合またはインターネットサービスプロバイダー (ISP) を通じて接続する場合はコンピュータの IP アドレスが静的ではない可能性があります。つまり、コンピュータの IP アドレスは動的で、コンピュータを再起動するたびに変化します。セキュリティグループルールで、ローカルコンピュータからのインバウンドトラフィックが許可されるようにするには**[Source]** (ソース) に単一の IP アドレスを指定するのではなく、クライアントコンピュータで使用されている IP アドレスの範囲を指定します。
セキュリティグループのルールの詳細については*Amazon VPCユーザーガイド*の[「セキュリティグループのルール」](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)を参照してください。
**サブネットのルートテーブルを確認します。**
VPC の外部あてのすべてのトラフィックを VPC のインターネットゲートウェイに送信するにはルートが必要です。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで [**インスタンス**] を選択し、インスタンスを選択してください。
1. [**ネットワーキング**] タブで、**VPC ID** と**サブネット ID** の値を書き留めます。
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインで、[**Internet Gateways**] を選択してください。ご使用の VPC にアタッチされているインターネットゲートウェイがあることを確認します。または[**インターネットゲートウェイの作成**] を選択し、インターネットゲートウェイの名前を入力して [**インターネットゲートウェイの作成**] を選択してください。次に、作成したインターネットゲートウェイで、[**アクション**]、[**VPC にアタッチ**]、[VPC] の順に選択し、[**インターネットゲートウェイのアタッチ**] をクリックして VPC にアタッチします。
1. ナビゲーションペインで [**Subnets**] を選択し、サブネットを選択してください。
1. [**ルートテーブル**] タブで、送信先として `0.0.0.0/0`、ターゲットとして VPC のインターネットゲートウェイが指定されたルートがあることを確認します。IPv6 アドレスを使用してインスタンスに接続する場合はインターネットゲートウェイを指しているすべての IPv6 トラフィック (`::/0`) 用のルートがあることを確認します。それ以外の場合は以下の作業を行います。
1. ルートテーブルの ID (rtb-*xxxxxxxx*) を選択して、ルートテーブルに移動します。
1. [**ルーター**] タブで、[**ルーター編集**] を選択してください。[**ルーター追加**] を選択して、`0.0.0.0/0` を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。IPv6 の場合は[**ルーター追加**] を選択して、`::/0` を送信先として追加し、インターネットゲートウェイをターゲットとして使用します。
1. [**ルーター保存**] を選択してください。
**サブネットのネットワークアクセスコントロールリスト (ACL) を確認します。**
ネットワーク ACL がポート 22 でローカル IP アドレスからのインバウンド SSH トラフィックを許可している必要があります。また、一時ポート (1024-65535) へのアウトバウンドトラフィックも許可する必要があります。
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. ナビゲーションペインで、[**サブネット**] を選択してください。
1. サブネットを選択する
1. [**ネットワーク ACL**] タブの [**インバウンドルール**] で、必要なポートでコンピュータからのインバウンドトラフィックを許可しているルールがあることを確認します。それが見つからない場合はコンピュータへのトラフィックをブロックしているルールを削除または変更します。
1. [**アウトバウンドルール**] で、一時ポートでコンピュータへのトラフィックを許可しているルールがあることを確認します。存在しない場合はコンピュータへのトラフィックをブロックしているルールを削除または変更します。
**コンピュータが社内ネットワークに接続されている場合**
社内ファイアウォールで、ご使用のコンピュータのインバウンドおよびアウトバウンドのトラフィックがポート 22 で許可されているかどうか、ネットワーク管理者に問い合わせてください。
ご使用のコンピュータにファイアウォールが設定されている場合、そのファイアウォールでコンピュータのインバウンドおよびアウトバウンドのトラフィックがポート 22 で許可されているかどうか確認します。
**インスタンスにパブリック IPv4 アドレスがあることを確認します。**
そうでない場合はElastic IP アドレスをインスタンスに関連付けることができます。詳細については、「[Elastic IP アドレス](elastic-ip-addresses-eip.md)」を参照してください。
**サーバーが過負荷になっている可能性のあるインスタンスの CPU 負荷を確認します。**
AWS は自動的に Amazon CloudWatch メトリクスおよびインスタンスステータスなどのデータを提供します。これらを使用することでインスタンスの CPU 負荷を確認でき、必要に応じて負荷の処理方法を調整できます。詳細については、「[CloudWatch を使用したインスタンスのモニタリング](using-cloudwatch.md)」を参照してください。
+ 負荷が変化する場合、[Auto Scaling](https://aws.amazon.com/autoscaling/) および [エラスティックロードバランシング](https://aws.amazon.com/elasticloadbalancing/) を使用して、インスタンスの増減を自動的に縮小・拡張できます。
+ 負荷が常に増加している場合、大きなインスタンスタイプに移動できます。詳細については、「[Amazon EC2 インスタンスタイプの変更](ec2-instance-resize.md)」を参照してください。
**IPv6 アドレスを使用してインスタンスに接続するには以下のことを確認します。**
+ サブネットはインターネットゲートウェイへの IPv6 トラフィック (`::/0`) のルートを持つルートテーブルに関連付けられている必要があります。
+ セキュリティグループルールではポート 22 でローカル IPv6 アドレスからのインバウンドトラフィックを許可する必要があります。
+ ネットワーク ACL ルールではインバウンドおよびアウトバウンドの IPv6 トラフィックを許可する必要があります。
+ 古い AMI からインスタンスを起動した場合、DHCPv6 用に設定されていない可能性があります (IPv6 アドレスはネットワークインターフェイスでは自動的に認識されません)。詳細については「*Amazon VPC ユーザーガイド*」の[「インスタンスに IPv6 を設定する」](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-dhcpv6)を参照してください。
+ ローカルコンピュータに IPv6 アドレスがあり、IPv6 を使用するように設定されている必要があります。
## エラー: キーを読み込めません..。期待: 任意のプライベートキー
インスタンスに接続しようとして、エラーメッセージ、`unable to load key ... Expecting: ANY PRIVATE KEY` が表示される場合、プライベートキーが保存されているファイルが正しく設定されていません。プライベートキーファイルが `.pem` で終わる場合でも、正しく設定されていない可能性があります。プライベートキーファイルが正しく設定されていない原因として考えられるのは証明書がないことです。
**プライベートキーファイルが正しく設定されていない場合は以下の手順に従ってエラーを解決する**
1. 新しいキーペアを作成します。詳細については、「[Amazon EC2 を使用してキーペアを作成する](create-key-pairs.md#having-ec2-create-your-key-pair)」を参照してください。
**注記**
サードパーティー製のツールを使用して、新しいキーペアを作成することもできます。詳細については、「[サードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートする](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws)」を参照してください。
1. 新しいキーペアをインスタンスに追加します。詳細については、「[プライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?](#replacing-lost-key-pair)」を参照してください。
1. 新しいキーペアを使用してインスタンスに接続します。
## エラー: ユーザーキーがサーバーによって認識されない
**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 インスタンスに接続する](connect-linux-inst-from-windows.md)を参照してください。
**注記**
PuTTYgen でプライベートキーファイルをロードし、[**Generate**] ではなく [**Save Private キー**] を選択してください。
+ AMI 用の適切なユーザー名で接続していることを確認します。**[PuTTY Configuration]** ウィンドウの **[ホスト名]** ボックスにユーザー名を入力してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)
+ 適切なポートへのインバウンドトラフィックを許可しているインバウンドセキュリティグループがあることを確認します。詳細については、「[コンピュータからのインスタンスへの接続ルール](security-group-rules-reference.md#sg-rules-local-access)」を参照してください。
## エラー: アクセス許可が拒否されたか、[インスタンス] ポート 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 |
| FreeBSD | 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
```
使用しているプライベートキーファイルが、インスタンスの起動時に選択したキーペアに対応していることを確認します。
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで [**インスタンス**] を選択し、インスタンスを選択してください。
1. [**詳細**] タブの [**インスタンスの詳細**] で、[**キーペア名**] の値を確認します。
1. インスタンスを起動したときにキーペアを指定しなかった場合はキーペアを確実に指定するために、インスタンスを終了してから新しいインスタンスを起動します。それまで使用していたインスタンスで、キーペアに対する `.pem` ファイルがもう存在しない場合はそのキーペアを新しいキーペアで置き換えることができます。詳細については、「[プライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?](#replacing-lost-key-pair)」を参照してください。
独自のキーペアを生成した場合はキージェネレータが RSA キーを作成するように設定されていることを確認します。DSA キーは受け入れられません。
`Permission denied (publickey)` エラーが表示され、上のいずれも当てはまらない場合 (例えば、以前は接続できていたなど)、インスタンスのホームディレクトリのアクセス権限が変更された可能性があります。`/home/instance-user-name/.ssh/authorized_keys` のアクセス権限は所有者のみに制限する必要があります。
**インスタンスのアクセス権限を検証するには**
1. インスタンスを停止し、ルートボリュームをデタッチします。詳細については、「[Amazon EC2 インスタンスの停止と開始](Stop_Start.md)」を参照してください。
1. 同じアベイラビリティーゾーンにある一時インスタンスを現在のインスタンスとして起動し (現在のインスタンスに使用したのと同様または同じ AMI を使用)、ルートボリュームを一時インスタンスにアタッチします。
1. 一時インスタンスに接続してマウントポイントを作成し、アタッチしたボリュームをマウントします。
1. 一時インスタンスから、アタッチされたボリュームの `/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
```
1. ボリュームをアンマウントして一時インスタンスからデタッチし、元のインスタンスに再アタッチします。ルートボリュームに適切なデバイス名を指定したことを確認します (`/dev/xvda` など)。
1. インスタンスを起動します。一時インスタンスが必要なくなった場合は終了できます。
## エラー: 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 インスタンスに接続する場合はローカルコンピュータに対して次の手順を実行します。
1. .pem ファイルに移動します。
1. .pem ファイルを右クリックし、[**プロパティ**] を選択してください。
1. [**セキュリティ**] タブを選択してください。
1. [**詳細**] を選択してください。
1. 自分がファイルの所有者であることを確認します。そうでない場合は所有者を自分のユーザー名に変更します。
1. [**継承の無効化**] および [**このオブジェクトから継承されたすべてのアクセス許可を削除**] を選択してください。
1. [**追加**]、[**プリンシパルの選択**] を選択し、ユーザー名を入力して、[**OK**] をクリックしてください。
1. [**許可エントリ**] ウィンドウから、**読み取り**アクセス許可を付与して、[**OK**] をクリックしてください。
1. **[Apply]** (適用) をクリックして、すべての設定が保存されているようにします。
1. [**OK**] をクリックして、[**セキュリティの詳細設定**] ウィンドウを閉じます。
1. [**OK**] をクリックして、[**プロパティ**] ウィンドウを閉じます。
1. Windows から SSH を使用して Linux インスタンスに接続できるはずです。
Windows のコマンドプロンプトから次のコマンドを実行します。
1. コマンドプロンプトから、.pem ファイルのファイルパスの場所に移動します。
1. 明示的なアクセス許可をリセットおよび削除するには次のコマンドを実行します。
```
icacls.exe $path /reset
```
1. 現在のユーザーに読み取りアクセス許可を付与するには次のコマンドを実行します。
```
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
```
1. 継承を無効にし、継承されたアクセス許可を削除するには次のコマンドを実行します。
```
icacls.exe $path /inheritance:r
```
1. 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 アドレスが変更されるためです。
このエラーを解決するには、まず、インスタンスのホストキーまたはネットワーク設定に予期された変更があったことを確認します。インスタンスに接続する前に、[ホストフィンガープリントを確認](connection-prereqs-general.md#connection-prereqs-fingerprint)することもお勧めします。インスタンスに接続したら、 `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 |
| FreeBSD | ec2-user |
| RHEL | ec2-user または root |
| SUSE | ec2-user または root |
| Ubuntu | ubuntu |
| Oracle | ec2-user |
| Bitnami | bitnami |
| Rocky Linux | rocky |
| その他 | AMI プロバイダーに確認してください。 |
次の点も確認する必要があります。
+ 最新バージョンの PuTTY を使用している。詳細については[PuTTY のウェブページ](https://www.chiark.greenend.org.uk/~sgtatham/putty/)を参照してください。
+ プライベートキー (.pem) ファイルが PuTTY によって認識される形式 (.ppk) に正しく変換されている。プライベートキーの変換の詳細については[PuTTY を使用して Linux インスタンスに接続する](connect-linux-inst-from-windows.md)を参照してください。
## インスタンスに対して 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 インスタンスでホストキーの検証に失敗したエラーを解決するには**
1. 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 インスタンスに接続する](connect-linux-inst-ssh.md)を参照してください。
1. 次のフォルダに移動します。
```
[ec2-user ~]$ cd /opt/aws/bin/
```
1. インスタンスで次のコマンドを実行します。
```
[ec2-user ~]$ ./eic_harvest_hostkeys
```
呼び出しが成功しても、出力されないことに注意してください。
これで、EC2 インスタントコネクト ブラウザベースのクライアントを使用してインスタンスに接続できます。
------
#### [ Ubuntu ]
**Ubuntuインスタンスでホストキーの検証に失敗したエラーを解決するには**
1. 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 インスタンスに接続する](connect-linux-inst-ssh.md)を参照してください。
1. 次のフォルダに移動します。
```
[ec2-user ~]$ cd /usr/share/ec2-instance-connect/
```
1. インスタンスで次のコマンドを実行します。
```
[ec2-user ~]$ ./eic_harvest_hostkeys
```
呼び出しが成功しても、出力されないことに注意してください。
これで、EC2 インスタントコネクト ブラウザベースのクライアントを使用してインスタンスに接続できます。
------
## EC2 インスタントコネクト を使用して Unbntu インスタンスに接続できない
EC2 インスタントコネクト を使用して Ubuntu インスタンスへの接続を試行中にエラーが発生した場合、次の情報を使用して問題の解決を試みることができます。
**考えられる原因**
インスタンス上の`ec2-instance-connect`パッケージは最新バージョンではありません。
**解決策**
次のように、インスタンス上の`ec2-instance-connect`パッケージを最新バージョンにアップデートします。
1. EC2 インスタントコネクト 以外の方法でインスタンスに[接続](connect-to-linux-instance.md)します。
1. インスタンス上で次のコマンドを実行して`ec2-instance-connect`パッケージを最新バージョンにアップデートします。
```
apt update && apt upgrade
```
## プライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?
EBS-Backed インスタンスのプライベートキーを失った場合はインスタンスへのアクセス権を回復することができます。インスタンスを停止し、そのルートボリュームをデタッチし、データボリュームとして別のインスタンスにアタッチし、新しいパブリックキーで `authorized_keys` ファイルを変更して、ボリュームを元のインスタンスに戻し、インスタンスを再起動する必要があります。インスタンスの起動、接続、および停止の詳細については[Amazon EC2 インスタンスの状態変更](ec2-instance-lifecycle.md)を参照してください。
この手順はEBS ルートボリュームを持つインスタンスでのみサポートされます。インスタンスにインスタンスストアのルートボリュームがある場合、この手順を使用してインスタンスへのアクセスを回復することはできません。インスタンスに接続するにはプライベートキーが必要です。インスタンスのルートボリュームタイプを判断するにはAmazon EC2コンソールを開き、**[インスタンス]** を選択してインスタンスを選択し、**[ストレージ]** タブを選択し、**[ルートデバイス詳細]** セクションで、**[ルートデバイスタイプ]** の値をチェックします。
この値は `EBS` または `INSTANCE-STORE` のどちらかです。
プライベートキーを紛失した場合、以下の手順以外にも Linux インスタンスに接続する方法があります。詳細については[最初の起動後に SSH キーペアを紛失した場合、Amazon EC2 インスタンスに接続するにはどうすればよいですか?](https://repost.aws/knowledge-center/user-data-replace-key-pair-ec2)を参照してください。
**Topics**
+ [ステップ 1: 新しいキーペアを作成する](#step-1-create-new-key-pair)
+ [ステップ 2: 元のインスタンスとそのルートボリュームに関する情報を取得する](#step-2-get-info-about-original-instance)
+ [ステップ 3: 元のインスタンスを停止する](#step-3-stop-original-instance)
+ [ステップ 4: 一時インスタンスを起動する](#step-4-launch-temp-instance)
+ [ステップ 5: 元のインスタンスからルートボリュームをデタッチし、一時インスタンスにアタッチする](#step-5-detach-root-volume-and-attach-to-temp-instance)
+ [ステップ 6: 一時インスタンスにマウントされた元のボリュームの `authorized_keys` に、新しいパブリックキーを追加する](#step-6-add-new-public-key-to-authorized_keys)
+ [ステップ 7: 一時インスタンスから元のボリュームをアンマウントしてデタッチし、元のインスタンスに再アタッチする](#step-7-unmount-detach-volume-and-reattach-to-original-instance)
+ [ステップ 8: 新しいキーペアを使用して元のインスタンスに接続する](#step-8-connect-to-original-instance)
+ [ステップ 9: クリーンアップする](#step-9-clean-up)
### ステップ 1: 新しいキーペアを作成する
Amazon EC2 コンソールまたはサードパーティ製のツールで、新しいキーペアを作成します。新しいキーペアの名前として、紛失したプライベートキーと同じ名前を指定するにはまず既存のキーペアを削除する必要があります。新しいキーペアの作成の詳細については[Amazon EC2 を使用してキーペアを作成する](create-key-pairs.md#having-ec2-create-your-key-pair)または[サードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートする](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws)を参照してください。
### ステップ 2: 元のインスタンスとそのルートボリュームに関する情報を取得する
この手順を完了するために必要になるので、次の情報を書き留めます。
**元のインスタンスに関する情報を取得するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで [**Instances**] を選択し、接続先にするインスタンスを選択します (このインスタンスを*元の*インスタンスと呼びます)。
1. [**Details**] タブで、インスタンス ID と AMI ID を書き留めます。
1. **[ネットワーキング]** タブで、アベイラビリティーゾーンを書き留めます。
1. [**Storage**] タブの [**ルートデバイス名**] で、ルートボリュームのデバイス名 (`/dev/xvda` など) を書き留めます。次に、[**Block devices**] で、このデバイス名を見つけ、ボリューム ID (vol-0a1234b5678c910de など) を書き留めます。
### ステップ 3: 元のインスタンスを停止する
[**インスタンスの状態**]、[**インスタンスの停止**] の順に選択してください。このオプションが無効になっている場合はインスタンスが既に停止しているか、またはルートボリュームがインスタンスストアボリュームです。
**警告**
インスタンスストアボリューム上のデータは、インスタンスを停止すると失われます。このデータを保持するには、永続ストレージにバックアップしてください。
### ステップ 4: 一時インスタンスを起動する
**一時インスタンスを起動するには**
1. ナビゲーションペインで **[Instances]** (インスタンス)、**[Launch instances]** (インスタンスの起動) の順に選択してください。
1. **[Name and tags]** (名前とタグ) セクションの **[Name]** (名前) に「**Temporary** (一時)」と入力してください。
1. **[Application and OS Images]** (アプリケーションと OS イメージ) セクションで、元のインスタンスの起動に使用したものと同じ AMI を選択してください。その AMI を使用できない場合は停止したインスタンスから使用可能な AMI を作成できます。詳細については、「[Amazon EBS-backed AMI を作成する](creating-an-ami-ebs.md)」を参照してください。
1. **[Instance type]** (インスタンスタイプ) セクションではデフォルトのインスタンスタイプを保持します。
1. **[キー pair]** (キーペア) セクションの **[キー pair name]** (キーペア名) で、使用する既存のキーペアを選択するか、新しいキーペアを作成します。
1. **[ネットワーク設定]** セクションで **[編集]** を選択し、次に **[サブネット]** で、元のインスタンスと同じアベイラビリティーゾーンのサブネットを選択してください。
1. **[Summary]** (サマリー) パネルで、**[Launch]** (起動) を選択してください。
### ステップ 5: 元のインスタンスからルートボリュームをデタッチし、一時インスタンスにアタッチする
1. ナビゲーションペインで **[ボリューム]** を選択し、元のインスタンスのルートボリュームを選択します (前のステップでそのボリューム ID を書き留めました)。**[アクションs]** (アクション)、**[Detach Volume]** (ボリュームのデタッチ)、**[Detach]** (デタッチする) の順に選択してください。ボリュームの状態が `available` になるまで待ちます ([Refresh] アイコンを選択しなければならない場合があります)。
1. ボリュームを選択したまま **[アクションs]** (アクション) を選択し、次に **[Attach Volume]** (ボリュームをアタッチ) を選択してください。一時インスタンスのインスタンス ID を選択し、**[Device name]** (デバイス名) で指定されたデバイス名 (例: `/dev/sdf`) を書き留めて、**[Attach volume]** (ボリュームをアタッチ) を選択してください。
**注記**
元のインスタンスを AWS Marketplace AMI から起動して、ボリュームに AWS Marketplace のコードが含まれている場合はボリュームをアタッチする前に一時インスタンスを停止する必要があります。
### ステップ 6: 一時インスタンスにマウントされた元のボリュームの `authorized_keys` に、新しいパブリックキーを追加する
1. 一時インスタンスに接続します。
1. 一時インスタンスから、そのファイルシステムにアクセスできるように、インスタンスにアタッチしたボリュームをマウントします。例えば、デバイス名が `/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`) をマウントします。
1. ボリュームをマウントするための一時ディレクトリを作成します。
```
[ec2-user ~]$ sudo mkdir /mnt/tempvol
```
1. 以前に特定したデバイス名またはボリューム名を使用して、一時マウントポイントにボリューム (またはパーティション) をマウントします。必要なコマンドはオペレーティングシステムのファイルシステムによって異なります。注意事項デバイス名の表示がインスタンスでは異なる場合があります。詳細についてはステップ 6 の[note](#device-name)を参照してください。
+ 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
```
1. 一時インスタンスから、次のコマンドを使用して、一時インスタンスの `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
```
1. (前のステップでアンマウントした) 一時インスタンスからボリュームをデタッチする: Amazon EC2 コンソールのナビゲーションペインで **[ボリューム]** を選択し、(前のステップでボリューム ID を書き留めた) 元のインスタンスのルートボリュームを選択し、**[アクション]**、**[ボリュームのデタッチ]** の順に選択してください。次に、**[デタッチ]** を選択してください。ボリュームの状態が `available` になるまで待ちます ([Refresh] アイコンを選択しなければならない場合があります)。
1. ボリュームを元のインスタンスに再アタッチする: ボリュームを選択した状態で、**[アクション]** (アクション)、**[Attach Volume]** (ボリュームをアタッチ) の順に選択してください。元のインスタンスのインスタンス ID を選択し、元のルートボリュームのアタッチメントについて先程の [ステップ 2](#step-2-get-info-about-original-instance) で記録したデバイス名 (`/dev/sda1` または `/dev/xvda`) を指定してから、**[ボリュームのアタッチ]** を選択してください。
**重要**
元のアタッチと同じデバイス名を指定しない場合、元のインスタンスを起動することはできません。Amazon EC2 はルートボリュームが `sda1` または `/dev/xvda` であることを想定しています。
### ステップ 8: 新しいキーペアを使用して元のインスタンスに接続する
元のインスタンスを選択し、[**インスタンスの状態**]、[**Start instance (インスタンスの開始)**] の順に選択してください。インスタンスが `running` 状態になったら、新しいキーペアのプライベートキーファイルを使用して、そのインスタンスに接続できます。
**注記**
新しいキーペアおよび対応するプライベートキーファイルの名前が元のキーペアの名前と異なる場合はインスタンスに接続するときに新しいプライベートキーファイルの名前を必ず指定します。
### ステップ 9: クリーンアップする
(オプション) 一時インスタンスをそれ以上使用しない場合は終了できます。一時インスタンスを選択し、**[インスタンスの状態]**、**[インスタンスの終了 (削除)]** の順に選択してください。