EC2接続完全攻略：PEMキー管理とポート設定、トラブルシューティングガイド

EC2インスタンスへの接続成功ロードマップ：PEMとポートの全体像

接続方法の多様化とセキュリティ強化の背景

近年、国内企業のクラウドサービス利用割合は2022年時点で72.2%（総務省「情報通信白書 令和5年版」）に達し、AWSは世界のクラウドインフラ市場で2023年第4四半期に31%のシェアを占めるなど、クラウド利用は急速に拡大しています。それに伴い、EC2インスタンスへの接続方法も多様化し、セキュリティ強化が喫緊の課題となっています。従来主流だったSSH接続に加えて、現在はIAM認証を用いた「EC2 Instance Connect」や「SSM Session Manager」など、より安全で運用負荷の低い接続方法が推奨されています。これは、設定ミスに起因するセキュリティインシデントが増加傾向にあるため、アクセス制御を最小限に抑える重要性が認識されているからです。

クラウドセキュリティにおける「責任共有モデル」では、インフラの物理的な保護はAWSの責任ですが、OSのログイン設定、IAM権限管理、セキュリティグループのルール設定といった「クラウド内のセキュリティ」は利用者側の責任となります。この利用者側の設定ミスが多くのトラブルやセキュリティリスクの原因となるため、正しい知識と設定が不可欠です。

SSH接続におけるPEMキーとポートの基礎知識

EC2インスタンスへのSSH接続には、キーペアの一部であるPEMファイル（秘密鍵）が不可欠です。このPEMファイルは、ユーザーの身元を認証し、安全な通信チャネルを確立するために使用されます。通常、SSH接続は標準で22番ポートを使用し、このポートに対して適切にセキュリティグループを設定する必要があります。セキュリティグループは、インスタンスへのインバウンドおよびアウトバウンドトラフィックを制御する仮想ファイアウォールとして機能します。

特に重要な注意点として、SSHポート（22番）を全インターネットに開放する「Anywhere (0.0.0.0/0)」設定は、サイバー攻撃の標的となるリスクが極めて高いため、絶対に行わないでください。許可するIPアドレスは、自身のPCのグローバルIPアドレス（「マイIP」）や、特定のネットワーク範囲に限定することが基本です。PEMキーの厳重な管理と、最小限のアクセス許可が、安全なSSH接続の基盤となります。

SSM Session ManagerとInstance Connectのメリット

AWSでは、従来のSSH接続の課題を解決し、セキュリティと運用効率を高めるために、SSM Session ManagerとEC2 Instance Connectという2つの接続方法を推奨しています。SSM Session Managerを利用する場合、インスタンスのインバウンドポート（22番ポートなど）を開放する必要がありません。代わりに、IAMポリシーによってアクセス制御が行われるため、攻撃対象領域が大幅に減少します。これは、セキュリティグループの設定ミスによるリスクを低減し、よりセキュアな運用を実現します。

一方、EC2 Instance Connectは、ブラウザから簡単にEC2インスタンスへ接続できるサービスです。SSHキーペアは必要ですが、マネジメントコンソールから一時的に公開鍵をインスタンスに登録する仕組みのため、手動での鍵管理の手間を省けます。これらのツールを活用することで、PEMキーの厳重な管理負荷を軽減しつつ、より堅牢なセキュリティ環境でEC2インスタンスにアクセスすることが可能になります。特に、複数のチームメンバーがインスタンスにアクセスする必要がある場合や、監査要件が厳しい環境でその真価を発揮します。

出典：総務省「情報通信白書 令和5年版」、総務省「令和6年版 情報通信白書」、IPA「情報セキュリティ白書」

初回接続からブラウザアクセスまで：具体的な設定ステップ

SSHキーペアの作成とインスタンス起動時の設定

EC2インスタンスへの最初の接続ステップとして、キーペアの作成は不可欠です。AWSマネジメントコンソールにログインし、「EC2」サービスへ移動後、左側のナビゲーションペインから「キーペア」を選択し、「キーペアを作成」をクリックします。キーペア名を設定し、PEM形式（またはPPK形式）を選択して作成すると、秘密鍵ファイル（.pem拡張子）がダウンロードされます。このPEMファイルは一度しかダウンロードできず、紛失すると再発行できないため、安全な場所に厳重に保管してください。

次に、EC2インスタンスを起動する際に、この作成したキーペアを選択します。インスタンスの作成ウィザードで「キーペア（ログイン）」の項目に到達したら、ドロップダウンメニューから先ほど作成したキーペア名を選んでください。この設定により、起動するインスタンスに公開鍵が自動的に設定され、対応する秘密鍵（PEMファイル）を使用してSSH接続が可能になります。

セキュリティグループの最小権限設定

EC2インスタンスへの接続を成功させるためには、セキュリティグループの適切な設定が不可欠です。インスタンス作成時に新しいセキュリティグループを設定するか、既存のセキュリティグループを使用します。最も重要なのは、SSHポート（デフォルトは22番）に対するインバウンドルールです。ここで「タイプ」を「SSH」、「ポート範囲」を「22」に設定し、「ソース」には「マイIP」または特定のIPアドレス範囲を指定してください。

「Anywhere (0.0.0.0/0)」を選択することは、インターネット上の誰からでもSSHポートにアクセス可能にしてしまうため、極めて高いセキュリティリスクを伴います。必ず自身のPCのグローバルIPアドレス（変動する場合は適宜更新）か、組織の固定IPアドレスに限定しましょう。これにより、不正アクセス試行からインスタンスを保護し、セキュリティインシデントのリスクを大幅に低減できます。

各種接続方法の実践手順

EC2インスタンスへの接続方法はいくつかあります。最も一般的なSSHクライアントからの接続では、まずダウンロードしたPEMファイルに適切なパーミッションを設定します。Linux/macOSの場合、ターミナルでchmod 400 your-key.pemを実行します。その後、ssh -i your-key.pem ec2-user@your-instance-public-ipコマンドで接続を試みます。ec2-userはAMIによって異なる場合があるため（例: Ubuntuの場合はubuntu）、使用しているAMIのデフォルトユーザー名を確認してください。

ブラウザから接続するEC2 Instance Connectを利用する場合は、マネジメントコンソールでインスタンスを選択し、「接続」ボタンをクリック、「EC2 Instance Connect」タブから「接続」を選択するだけで簡単にアクセスできます。また、SSM Session Managerを利用する場合は、インスタンスにSSMエージェントがインストールされており、適切なIAMインスタンスプロファイルが付与されていることを確認し、マネジメントコンソールからセッションを開始します。これらの方法を使い分けることで、状況に応じた最適な接続が可能です。

「Permission denied」や接続不可！状況別トラブル解決策

最も多い「Permission denied」の原因と対処法

EC2インスタンスへのSSH接続で「Permission denied (publickey)」エラーが発生する場合、主な原因はキーペアの認証失敗です。まず、PEMファイルのパーミッションが正しく設定されているかを確認してください。LinuxやmacOSでは、秘密鍵ファイルは所有者のみ読み取り可能である必要があります。コマンドchmod 400 your-key.pemを実行し、パーミッションを修正してください。

次に、正しいPEMファイルを使用しているか、そしてインスタンス起動時に指定したキーペアと一致しているかを再確認しましょう。また、インスタンスへのログインに使用するユーザー名が間違っていることも頻繁にあります。Amazon Linuxではec2-userですが、Ubuntuの場合はubuntu、CentOSではcentosなど、AMIによってデフォルトユーザー名が異なります。使用しているAMIのドキュメントを確認し、正しいユーザー名で接続を試みることが重要です。

接続タイムアウトや拒否の原因とネットワーク確認

SSH接続時に「Connection timed out」や「Connection refused」というエラーが表示される場合、ネットワーク設定に問題がある可能性が高いです。まず、EC2インスタンスが起動しており、ステータスチェックに異常がないかAWSマネジメントコンソールで確認してください。次に、インスタンスに設定されているセキュリティグループのインバウンドルールを見直します。

SSH（22番ポート）が許可されているか、そしてその「ソース」IPアドレスが現在接続を試みているPCのグローバルIPアドレスと一致しているかを厳密に確認してください。「Anywhere (0.0.0.0/0)」以外の特定IPアドレスを設定している場合は、自身のIPアドレスが変更されていないかもチェックが必要です。さらに、まれにVPCのネットワークACL（NACL）がSSHトラフィックをブロックしている可能性もあります。AWSが提供する「EC2 インスタンスへの接続に関する問題のトラブルシューティング」ドキュメントを参照することで、段階的な問題解決が可能です。

出典：AWS公式ドキュメント「EC2 インスタンスへの接続に関する問題のトラブルシューティング」

最終手段としてのSSMとシリアルコンソールの活用

通常のSSH接続が困難な状況でも、EC2インスタンスへのアクセスを試みる最終手段として、SSM Session ManagerとEC2シリアルコンソールが非常に有効です。SSM Session Managerは、インスタンスにSSMエージェントがインストールされており、適切なIAMインスタンスプロファイルがアタッチされていれば、PEMキーやポート開放なしでセキュアにアクセスできます。ネットワーク設定の問題でSSHがブロックされている場合でも、SSMを通じてOSレベルの操作が可能になるため、トラブルシューティングに大いに役立ちます。

さらに深刻なケース、例えばインスタンスがネットワーク的に到達不能でSSMも利用できない場合、EC2シリアルコンソールが最後の砦となる可能性があります。これは、物理コンソールに直接接続するのと同様の機能を提供し、OSが起動しない状態やネットワーク設定が破損している状態でも、ブートプロセスやカーネルメッセージを確認し、デバッグ作業を行うことができます。これらのツールは、事前に設定が必要ですが、緊急時の復旧時間を大幅に短縮する強力な手段となります。

接続時のセキュリティリスクとよくある失敗パターン

「Anywhere (0.0.0.0/0)」開放の深刻なリスク

EC2インスタンスへの接続において、最も避けるべき設定の一つが、セキュリティグループのSSHポート（22番）を全インターネットに開放する「Anywhere (0.0.0.0/0)」設定です。この設定は、文字通り世界中のあらゆるIPアドレスからのSSH接続を許可するため、サイバー攻撃の標的となるリスクが極めて高まります。IPAの「情報セキュリティ白書」でも、クラウド利用時のインシデントの多くが利用者側の「設定ミス」に起因すると指摘されており、この「Anywhere」開放はその典型的な例です。

ポートスキャンやブルートフォースアタックの標的となり、不正ログインを許してしまう可能性があります。これにより、インスタンス内のデータ窃取、改ざん、あるいは踏み台にされて他のシステムへの攻撃源となるなど、甚大な被害につながる恐れがあります。許可するIPアドレスは必ず「マイIP」や、VPNなどで接続された特定のネットワーク範囲に限定し、最小限のアクセス権限を維持することが絶対条件です。

不適切なキーペア管理とIAM権限の過剰付与

PEMキーの管理は、EC2インスタンスのセキュリティを左右する重要な要素です。PEMキーの紛失はインスタンスへのSSH接続不能に直結し、再発行ができないため、最悪の場合はインスタンスの再構築が必要になります。また、PEMキーが漏洩した場合、不正アクセスを許すことになり、深刻なセキュリティインシデントに発展する可能性があります。キーペアは厳重に管理し、決して安易に共有したり、公開リポジトリにアップロードしたりしないでください。

さらに、IAMユーザーやロールに、必要以上の広範な権限を与えてしまう「最小権限の原則」違反もよくある失敗パターンです。例えば、インスタンスの接続権限だけでなく、終了権限（ec2:TerminateInstances）やIAMの管理権限（iam:*）などを誤って付与してしまうと、意図しないリソースの削除やアカウント乗っ取りのリスクを高めてしまいます。常に「必要な権限のみを、必要な期間だけ付与する」という原則を徹底することが重要です。

責任共有モデルにおける利用者の責任範囲

クラウド環境でのセキュリティを考える上で、「責任共有モデル」の理解は不可欠です。このモデルでは、AWSは「クラウドのセキュリティ」、つまり物理インフラ、ハードウェア、ネットワーク、仮想化基盤といったサービスの基盤部分のセキュリティに責任を持ちます。一方で、利用者は「クラウド内のセキュリティ」に責任を持ちます。

これは、ゲストOSのログイン設定、IAM権限管理、セキュリティグループやネットワークACLのルール設定、データの暗号化、そしてアプリケーションレベルのセキュリティ対策など、利用者が構成・管理する全てのリソースに対するセキュリティを意味します。IPAの報告が示す通り、クラウド利用におけるインシデントの多くが利用者側の設定ミスに起因しており、この責任範囲を明確に認識し、適切なセキュリティ対策を講じることが、利用者の義務となります。定期的なセキュリティレビューと設定の監査を通じて、脆弱性を未然に防ぐ努力が求められます。

出典：IPA「情報セキュリティ白書2024」、AWS公式ドキュメント「EC2 インスタンスに接続する」

【ケース】重要なPEMファイルを誤って削除し接続不能になった場合の復旧

PEMファイル削除時の状況と影響

架空のケースとして、ある開発者が重要な開発環境のEC2インスタンスにSSHで接続するために使用していたPEMファイルを、誤って自身のローカル環境から削除してしまったとします。このPEMファイルはバックアップを取っておらず、削除後は完全に失われた状態です。この状況下では、既存のSSHクライアントからのインスタンスへの接続は不可能となります。

なぜなら、SSH接続はPEMファイル（秘密鍵）とEC2インスタンスに設定されている公開鍵とのペアによる認証を必要とするためです。秘密鍵がなければ認証できず、結果としてインスタンスへのアクセスが完全に途絶えてしまいます。この影響により、開発作業は停止し、緊急の対応が求められる深刻な事態となります。PEMキーは一度作成すると再発行できないというAWSの仕様が、この事態をより一層深刻なものとします。

復旧のための代替手段とインスタンス再作成の検討

PEMファイルを削除してしまい、SSH接続が不能になった場合の復旧は非常に困難ですが、いくつかの代替手段が考えられます。もし事前にSSM Session Managerが設定され、インスタンスに適切なIAMロールが付与されていた場合は、PEMキーなしでSSH接続と同等の操作が可能です。これは、事前の準備が重要であることを示唆しています。

SSMが利用できない場合の現実的な選択肢は、インスタンスを再作成することです。まず、既存のインスタンスからAMI（Amazon Machine Image）を作成するか、データボリュームのスナップショットを取得します。次に、新しいキーペアで新しいEC2インスタンスを起動し、そのインスタンスに作成したAMIまたはスナップショットから復元したデータボリュームをアタッチすることで、実質的に元の環境を新しいインスタンス上に再現します。このプロセスにはデータロスのリスクやダウンタイムを伴う可能性があるため、慎重な計画と実施が必要です。

今後の対策とセキュリティ強化

PEMファイルの誤削除による接続不能という事態を繰り返さないために、今後の対策を講じることが重要です。まず、PEMファイルは複数の安全な場所にバックアップを分散して保管することを徹底してください。例えば、暗号化されたストレージや、セキュリティが確保された場所に保存することが考えられます。次に、可能な限りSSH接続への依存を減らし、SSM Session Managerへの移行を検討しましょう。

SSM Session Managerは、キーペア不要でIAMポリシーによるアクセス制御が可能であり、監査ログも残るため、セキュリティと運用管理の双方で大きなメリットがあります。チームで利用する場合は、キーペアの共有方法や管理ポリシーを明確にし、アクセス権限を最小限に抑えるよう定期的に見直しましょう。さらに、AWSアカウント全体のセキュリティ強化として、IAMユーザーへのMFA（多要素認証）導入も検討し、セキュリティを多層的に構築することが重要です。

出典：AWS公式ドキュメント「EC2 インスタンスに接続する」