セキュリティグループ、キーペア、ネットワーク構成などに関する問題を解決する方法を学び、Amazon EC2インスタンスへのシームレスなアクセスを実現してください。
Updated by 高橋明哲 on 2026/01/14
AWS を初めて利用するユーザーのなかには、SSH 経由で Linux EC2 インスタンスに接続する際に問題に直面する人もいます。ご安心ください。この記事では、よくある原因のトラブルシューティング方法をご紹介します！
SSHを介してEC2に接続できない主な理由は、一般的に接続タイムアウトと権限エラーの2つのカテゴリに分けられます。
接続タイムアウト： 「connect」といったキーワードを含むエラーメッセージがあります。例として"Connection Timed Out"があります。これは一般的にネットワーク設定の不備が原因です。IP、セキュリティグループ、ACL、サブネットルートテーブル、ユーザーのネットワーク環境を確認する必要があります。
権限エラー: エラーメッセージには通常「permission（権限）」や「key（キー）」などのキーワードが含まれており、「Permission Denied（権限が拒否されました）」や、キーが登録されていない、または存在しないという警告などが該当します。これは一般的に、キーまたはユーザー名の使用方法が正しくないことが原因です。
問題の説明
Amazon EC2のLinuxインスタンスを作成して起動したものの、SSHやPuTTYなどのツールを使用してインスタンスに接続できないという問題があります。インスタンスへの接続時に、「Network error: Connection timed out（ネットワークエラー: 接続がタイムアウトしました）」や「Error connecting to [instance], reason: -> Connection timed out: connect（[インスタンス]への接続エラー、理由: → 接続がタイムアウトしました: 接続）」といった接続タイムアウトのエラーが発生します。この問題は通常、セキュリティグループ、ルートテーブル、ネットワークACLなどのネットワークコンポーネントの設定が正しくないことが原因です。以下のトラブルシューティング手順に従って、ネットワーク環境を確認してください。
1. セキュリティグループを確認する
EC2インスタンスのセキュリティグループで、SSHプロトコルの受信トラフィック（デフォルトポート22）が許可されていることを確認してください。
オフィスのLAN内では、IPアドレスが固定されておらず、接続するたびに変更される場合があります。この場合、単一のIPではなく、オフィスネットワークのIP範囲をソースとして設定することをお勧めします。
注意： デフォルトでは、インスタンスはpingできません。このインスタンスをpingしたい場合は、ICMPプロトコルを許可するルールを同様の方法で追加する必要があります。
Amazon EC2コンソールを開きます。
ナビゲーションペインで、インスタンス を選択します。
SSH経由で接続したいEC2インスタンスを見つけます。
画面下部の説明 タブで、接続したいEC2インスタンスのセキュリティグループを選択します。
画面下部のペインにあるInbound タブで、現在のパブリックIPアドレスからのSSHアクセスを許可するルールが設定されていることを確認します。デバイスで使用しているIPアドレスが一覧にない場合は、Editを選択し、次にAdd ruleを選択します。
ソースとして、ご自身の現在のIPアドレスを選択してください。「0.0.0.0/0」という設定は、すべてのIPアドレスに公開されていることを意味します。
保存 を選択します。
2. サブネットがパブリックサブネットかどうかを確認します
パブリックサブネットはインターネットアクセスを許可するサブネットです。EC2がプライベートサブネット内にある場合、外部のインターネットからは主动的な接続が行えず、SSHも失敗します。
Amazon VPCコンソールを開きます。
ナビゲーションペインで ルートテーブル を選択し、一覧から自分のVPCルートテーブルを選択します。
ルートタブで、インターネットゲートウェイを指すデフォルトルートが存在することを確認します。
ない場合は、ナビゲーションペインからインターネットゲートウェイを選択し、インターネットゲートウェイIDをコピーしてください。インターネットゲートウェイがない場合は、新しく作成してVPCに接続してください。新しいインターネットゲートウェイIDをコピーしてください。
ルートテーブルに戻り、次にルートタブを選択します。
「0.0.0.0/0」をインターネットゲートウェイIDにルーティングするルートを編集および作成します。
ルートテーブルを保存します。
3. サブネットのネットワークアクセス制御リスト（ACL）を確認する
ACLはサブネットレベルのファイアウォールです。デフォルトのネットワークACLは、すべてのインバウンドおよびアウトバウンドトラフィックを許可します。ACLに変更を加えていない場合は、この手順をスキップしてください。
Amazon VPCコンソールを開きます。
ナビゲーションペインで サブネット を選択し、次に自分のサブネットを選択します。
説明タブで ネットワークACL を見つけ、その後そのID (acl-xxxxxxxx) を選択します。
ネットワークACLを選択します。インバウンドルールで、ルールがあなたのコンピュータからのトラフィックを許可しているか確認してください。許可していない場合は、あなたのコンピュータからのトラフィックをブロックするルールを削除または変更してください。アウトバウンドルールで、ルールがあなたのコンピュータへのトラフィックを許可しているか確認してください。許可していない場合は、あなたのコンピュータへのトラフィックをブロックするルールを削除または変更してください。
4. IPアドレスが変更されたか確認する
ナビゲーションペインで、[インスタンス] を選択します。
SSH経由で接続したいEC2インスタンスを見つけます。
画面下部の説明タブで、パブリックIPが使用しているIPアドレスと一致しているか確認してください。IPアドレスが変更されている場合は、新しいIPアドレスを使用してください。
5. AMIを確認する
現在使用しているAMIがクイックスタートにあるか、マーケットプレイスにあるかを確認してください。コミュニティイメージは特定のAMIの安全性を保証するものではなく、避けて使用することが推奨されます。コミュニティイメージは個人によって提供されており、AWSではその監視を行うことができません。一部のコミュニティイメージには特別なセキュリティ管理と制御が施されており、直接のSSHアクセスができない場合があります。このような場合は、現在のサーバーを停止し、公式またはマーケットプレイスのAMIで新しいサーバーを起動してください。
6. インスタンスの負荷を確認する
サーバーが過負荷になっている可能性があり、そのためにsshdサービスが正常に動作せず、新しいSSH要求を受け付けない状態になっています。これはCloudWatchメトリクスを観察することで確認できます。この状況で最も簡単な方法は、インスタンスを再起動して問題が解決するか試すことです。そうでない場合は、System Managerのセッションマネージャー・ツールを使用してセッションを開き、不要なリソースを終了するコマンドを実行します。
7. その他の理由
上記のすべての手順を確認しても問題がない場合は、以下の原因を確認してください：
ポート22がブロックされています：オフィスやホテルの公共Wi-Fiエリアにいる場合は、別のネットワークを使用して、公共ネットワークがポート22をブロックしているか確認してください。
ご使用のコンピューターのファイアウォールがポート22をブロックしていないか確認してください。
問題の説明
EC2を作成して起動しましたが、SSHでインスタンスに接続できず、「ホストキーが[ディレクトリ]に見つからない」、「アクセス拒否 (公開キー)」、「認証に失敗しました。アクセスが拒否されました」などのエラーメッセージが表示されます。この問題は通常、キーまたはユーザー名が正しくないことが原因です。以下は具体的なトラブルシューティング方法です。
1. キーペアが正しいか確認する
各EC2インスタンスは起動時にキーペアを持ちます。このキーペアはEC2に初めてログインする際の唯一の方法であり、インスタンスを起動する前にのみダウンロードできます。まず、自分のインスタンスを選択し、説明 ページでキーペア名を確認して、正しいキーペアを使用していることを確認してください。
この項目が空の場合、インスタンスにSSH接続することはできません。インスタンスを停止し、新しいインスタンスを起動してください。また、キーをダウンロードすることを忘れないようにしてください。
2. ユーザー名が正しくありません
公式イメージを使用している場合、正しいユーザー名は以下の通りです：
AMI | ユーザー名 |
Amazon Linux 2 または Amazon Linux AMI | ec2-user |
CentOS AMI | centos |
Debian AMI | 管理者 または ルート |
Fedora AMI | ec2-user または fedora |
RHEL AMI | ec2-user または root |
SUSE AMI | ec2-user または root |
Ubuntu AMI | ウブントゥ |
AMIがコミュニティ版の場合、ユーザー名を保証することはできません。AMIの作成者にご確認いただくか、公式AMIへの切り替えをご検討ください。
3. キー形式を確認してください
一般的に、SSHに必要な鍵は「pem」形式です。Windowsマシンを使用していてPuTTYでログインする場合は、「pem」形式を「ppk」形式に変換する必要があります。
4. 重要な権限を確認する
エラー「bad permissions: ignore key: my_private_key.pem Permission denied (publickey)」が発生した場合。
この状況は、秘密鍵ファイルの権限が高すぎるので、どのユーザーでも読み書きできてしまうため発生します。秘密鍵ファイルを保護するために、SSHはあなたの鍵を無視します。解決策は、次のコマンドを使用して鍵の権限を変更することです：
chmod 400 my_private_key.pem
5. known_host に関するエラー
この状況は、例えばEIPをマシンAからキーAを使ってマウントしていた場合に、そのEIPをキーBを使ってマシンBに切り替えると、このIPアドレスのknown_hostレコードが一致しなくなります。
解決策は、known_hostファイルを開き（Linux/macアドレス：~/.ssh/known_host）、このIPアドレスに対応するレコードを削除することです。
Vinchin Backup & Recovery はAWS EC2のバックアップをサポートしており、ユーザーはAWSアクセスキーIDを使用してインスタンスを追加し、フル、増分、差分バックアップの設定が可能です。全体的なインスタンス、個別のボリューム、特定のファイルなど、柔軟な復元オプションを提供し、他の仮想化プラットフォームへの直接復元も可能です。Amazon S3と連携し、安全なアーカイブを実現しています。また、 V2V移行 をVMware、Hyper-V、Proxmoxなどのプラットフォームで実行することも可能です。使いやすいインターフェースにより、バックアップの管理と設定が簡単になります。
EC2インスタンスをVinchin Backup & Recoveryでバックアップするには、次の手順に従ってください:
1. バックアップするEC2インスタンスを選択します。
2. バックアップ先を選択します。
3. バックアップ戦略を選択します。
4. 案件を確認して送信する。
安全でリソース効率の高いバックアップソリューションを体験するために、Vinchin Backup & Recovery の60日間無料トライアル を始めましょう。または、ITニーズに合わせたカスタマイズプランをご希望の場合は、お問い合わせください。
上記の手順により潜在的な問題を解決することで、問題を迅速に解消し、インスタンスへのアクセスを再取得できます。信頼できるIPアドレスのみにアクセスを制限したり、セキュリティグループやネットワーク設定を定期的に見直すなど、良いセキュリティ習慣を常に実践してください。
共有:
