EC2インスタンスを作成したものの、なぜかSSH接続ができずにお困りではありませんか？「タイムアウトで繋がらない」「権限エラーが出る」といったトラブルは、AWS運用において誰もが一度は直面する非常に厄介な壁です。かくいう私も、久しぶりにEC2へ接続しようとして「あれ、なんで繋がらないんだっけ…」となった経験が何度もあります。
結論から言うと、SSH接続ができない原因は「ネットワーク設定」「認証情報」「OSの仕様変更」のいずれかに集約されます。
この記事では、表示されるエラーメッセージから原因を特定する「逆引き診断」を軸に、セキュリティグループの設定から最新のAmazon Linux 2023の仕様まで、具体的な解決策をステップバイステップで解説。読み終える頃には、あなたのEC2は確実に接続可能な状態になっているはずです。ぜひ最後まで読み進めてください。
【診断】エラーメッセージでわかる原因の切り分け
EC2への接続トラブルを最短で解決する秘訣は、画面に表示されたエラーメッセージを正しく読み取ることです。エラーの内容によって、問題が「ネットワークの入り口」にあるのか、それとも「認証の手順」にあるのかを瞬時に判断できます。
具体的には、代表的な以下の2つのエラーを区別してください。
- Network error: Connection timed out
- これは、あなたのPCから送られた接続要求がEC2インスタンスに届いていない、あるいは無視されている状態を指します。主な原因は、セキュリティグループやルートテーブルといったネットワーク設定の不備です。
- Permission denied (publickey)
- 接続要求自体はインスタンスに届いていますが、鍵（.pem）やユーザー名の不一致により、ログインが拒否されています。この場合は、ネットワーク設定ではなく、認証情報の確認を優先すべきです。
まずは、お使いのターミナルに表示されている文字列をよく確認しましょう。また、Tera Termなどの外部ソフトでうまくいかない場合は、Windows標準のPowerShellから「ssh -i “秘密鍵のパス” ユーザー名@パブリックIP」とコマンドを打ってみてください。これによって、ソフト自体の設定ミスか、AWS側の設定ミスかをさらに明確に切り分けることができます。
原因①：ネットワーク設定の不備（Time Outが発生する場合）
「Connection timed out」が表示される場合、通信がインスタンスまで到達できていません。このセクションでは、インフラの土台となるネットワーク設定を2つのステップで確認します。
セキュリティグループの「インバウンドルール」を確認
接続トラブルの最も多い原因は、セキュリティグループでSSH通信が許可されていないことです。AWSコンソールの「インバウンドルール」を開き、ポート22（SSH）が開放されているかチェックしてください。
ここで注意すべき点は、接続を許可する「ソース（送信元）」の設定です。セキュリティ向上のため、全ての接続を許可する「0.0.0.0/0」の設定は推奨されません。必ず「マイIP」を選択し、現在の作業環境のグローバルIPアドレスからのみ接続を許可する設定に変更しましょう。自宅やオフィスのネットワーク環境が変わるとIPアドレスも変動するため、久しぶりに接続する場合は再設定が必要です。
VPC・サブネットのルートテーブルとIGW
セキュリティグループに問題がない場合、ネットワーク経路そのものに不備がある可能性を疑います。まず、EC2インスタンスが「パブリックサブネット」に配置されているかを確認してください。
チェックポイントは以下の3点です。
- インターネットゲートウェイ（IGW）: VPCにIGWがアタッチされているか。
- ルートテーブル: サブネットに関連付けられたルートテーブルに、送信先「0.0.0.0/0」かつターゲットが「igw-xxxx（上記IGW）」のレコードが存在するか。
- パブリックIPの有無: インスタンス詳細画面で「パブリック IPv4 アドレス」が割り当てられているか。
プライベートサブネットにインスタンスを作成してしまった場合、外部から直接SSH接続することはできません。コンソール画面でこれらのステータスを一つずつ照らし合わせ、通信の通り道を確保しましょう。
原因②：接続情報・認証ミス（Permission deniedが発生する場合）
ネットワークの疎通は取れているものの、ログインが拒否される「Permission denied」は、鍵の不一致や設定情報の入力ミスが原因です。以下のポイントを一つずつ照合してください。
ユーザー名がAMIごとに異なっていないか
EC2へ接続する際のユーザー名は、任意に決めるものではなく、使用しているOS（AMI）によってデフォルト値が決まっています。例えば、Amazon Linux系では「ec2-user」ですが、Ubuntuでは「ubuntu」を使用しなければなりません。
代表的なAMIのユーザー名は以下の通りです。
| OS / AMI名 | デフォルトユーザー名 |
| Amazon Linux 2023 / 2 | ec2-user |
| Ubuntu | ubuntu |
| CentOS | centos または ec2-user |
| Debian | admin |
| RHEL / Fedora | ec2-user |
よくある失敗として、管理者権限を意識するあまり「root」でログインしようとするケースがありますが、多くのAMIではセキュリティ上、rootでの直接接続は制限されています。必ず適切なユーザー名でログイン後、必要に応じて sudo コマンドを使用しましょう。
秘密鍵（.pem）の指定と管理の注意点
認証の核心となるのが秘密鍵（.pemファイル）です。Tera Termを使用する場合、ホスト名を入力した後の「SSH認証」画面で正しい秘密鍵ファイルを読み込ませているか再確認してください。
また、Windows 10/11のPowerShellやコマンドプロンプト（OpenSSH）から接続する場合、秘密鍵のアクセス権限（パーミッション）が広すぎると、セキュリティエラーで接続を拒否されることがあります。この場合は、ファイルのプロパティから自分以外のユーザー権限を削除するなどの対応が必要です。
【最重要】 秘密鍵はインスタンス作成時に一度だけダウンロードできるものであり、紛失してもAWS側から再発行はできません。万が一鍵を紛失し、他に接続手段がない場合は、インスタンスの再構築や「EC2 Instance Connect」を用いた緊急ログインを検討する必要があります。
原因③：最新の仕様変更とSSHクライアントの相性
これまでと同じ手順で設定しているにもかかわらず接続できない場合、OSの仕様変更やクライアントソフトのバージョンが原因かもしれません。特に最新の「Amazon Linux 2023（AL2023）」では、セキュリティ強度の向上のために古い規格が切り捨てられています。
Amazon Linux 2023におけるRSAキーの非推奨化
最新のAL2023では、セキュリティの脆弱性を防ぐため、従来の「ssh-rsa」形式の公開鍵暗号アルゴリズムがデフォルトで無効化されました。これにより、古いRSA形式のキーペアを使用していると、ネットワーク設定が正しくても認証で弾かれてしまいます。
解決策として、これから新しいインスタンスを作成する場合は「ed25519」形式のキーペアを選択することを強く推奨します。ed25519は現在の標準的なアルゴリズムであり、より高いセキュリティと処理速度を両立しています。既存のRSAキーをどうしても使い続けたい場合は、OS側の設定変更が必要になりますが、安全性の観点からは新しい鍵への移行がベストです。
Tera Termのバージョンによる挙動の違い
Windowsユーザーに愛用されている「Tera Term」ですが、古いバージョン（4.x系など）を使用していると、前述のAL2023で採用されている最新の暗号化方式に対応できず、エラーを吐くことがあります。
もし長年同じTera Termを使い続けているのであれば、まずは公式サイトから最新版（5.x系以上）をインストールしてください。最新バージョンでは、新しいアルゴリズムへの対応はもちろん、OpenSSHとの互換性も向上しているため、ソフトウェア由来のトラブルを未然に防ぐことができます。
それでも解決しない場合の最終チェックリスト
主要な設定を見直しても接続できない場合、OS内部の不具合や特殊なステータスに陥っている可能性があります。以下のチェックリストを順に確認し、原因を切り分けましょう。
インスタンスのステータスチェックを確認
AWSコンソールのインスタンス一覧で、「ステータスチェック」の項目を見てください。ここが「2/2 のチェックに合格しました」となっていない場合、インスタンス自体が正常に起動していません。
「システムステータスチェックの失敗」はAWS側のハードウェアトラブルの可能性があり、「インスタンスステータスチェックの失敗」はOSの起動プロセスやネットワーク設定のミス（静的IPの誤設定など）が疑われます。この場合は、インスタンスの停止・開始（再起動）を試すのが有効です。
OS側の設定ミスを疑う
以前は接続できていたのに、設定を変更した直後から繋がらなくなった場合は、OS内部の /etc/ssh/sshd_config の編集ミスが考えられます。また、OS側のファイアウォール（iptablesやufw）でポート22を閉じてしまった場合も、外部のセキュリティグループ設定に関わらず遮断されます。
最終手段：代替ログイン手法の試行
どうしてもSSHクライアントから繋がらない場合、以下のツールを使用して「中から」設定を確認できます。
- EC2 Instance Connect: ブラウザベースで直接シェルを操作できます。Amazon Linux 2なら標準で利用可能です。
- AWS Systems Manager（SSM）セッションマネージャー: インスタンスにSSMエージェントが導入されており、適切なIAMロールが付与されていれば、SSHポートを開放せずにブラウザやCLIからログインできます。
これらでログインできるのであれば、ネットワーク経路（セキュリティグループやPC側の環境）に原因があることが確定します。
まとめ
EC2へのSSH接続トラブルは、エラーメッセージを正しく読み解けば必ず解決できます。まずは「タイムアウト」か「認証拒否」かを見極め、設定を一つずつ見直してみましょう。
今回の重要ポイントは以下の3点です。
- ネットワーク設定の再確認: セキュリティグループの「マイIP」設定や、インターネットゲートウェイへのルートが正しく定義されているかチェックする。
- 認証情報の整合性: 使用しているOS（AMI）に対してユーザー名が正しいか、秘密鍵の形式や権限が適切かを今一度確認する。
- 最新仕様への対応: Amazon Linux 2023などの新OSでは、古いRSAキーやクライアントが拒否されるケースがあるため、最新の暗号化方式（ed25519）を検討する。
無事に接続できた後は、運用効率を高めるためにElastic IPの固定や、踏み台サーバーの構築など、よりセキュアで便利な環境作りにも挑戦してみてください。
AWSをさらに深く学びたい方には 以下の書籍がおすすめです。
 | AWSの基本・仕組み・重要用語が全部わかる教科書 [ 川畑光平 ] 価格:2970円 |
 | AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー 改訂第3版 [ 山下光洋 ] 価格:2970円 |
「※本記事にはアフィリエイトリンクが含まれています」
AWSの基礎から実践まで体系的に 学べる一冊です。
コメント