EC2へのSSH接続は、起動時に指定したキーペアの秘密鍵を使い、AMIごとに決まったユーザー名で ssh -i 秘密鍵 ユーザー名@パブリックIP と実行するのが基本です。この記事では、キーペアの作り方と保管、OS別のユーザー名、~/.ssh/config での接続の簡略化、接続できないときのエラー別の確認、鍵の追加・入れ替え、秘密鍵を紛失したときの復旧方法までを説明します。
コンソールの画面や対応する鍵の種類は変わることがあるため、ここでの説明は2026年10月現在の情報をもとにした目安です（2026年10月現在）。
キーペアの仕組みを理解する
EC2のキーペアは、公開鍵と秘密鍵の組です。AWSは公開鍵だけを保存し、インスタンスの初回起動時にその公開鍵をOSのユーザーの ~/.ssh/authorized_keys に書き込みます。秘密鍵は手元にだけ置かれ、AWS側には残りません。
この仕組みから、2つのことが分かります。1つは、秘密鍵をなくしてもAWSから再ダウンロードはできないこと。もう1つは、起動後にコンソールでキーペアの設定を変えても、すでに動いているインスタンスの authorized_keys は書き換わらないことです。鍵を変えたいときは、サーバーの中のファイルを直接編集します。
キーペアを用意する
コンソールで作る
EC2の画面の「キーペア」から作成します。鍵の種類はRSAとED25519から選べます。Linuxのインスタンスなら、鍵が短く処理も速いED25519が扱いやすい選択です。ただしWindowsのインスタンスではED25519が使えないため、RSAを選びます。ファイル形式は、OpenSSHで使う .pem と、PuTTYで使う .ppk から選べます。
作成すると秘密鍵のファイルがその場で1回だけダウンロードされます。このファイルをパスワードマネージャーや暗号化されたストレージにも保管しておくと、PCの故障で失う危険を減らせます。
手元で作った鍵をインポートする
自分のPCで作った鍵の公開鍵だけをAWSに登録する方法もあります。秘密鍵がネットワークを通らないことと、パスフレーズを付けられることが利点です。
ssh-keygen -t ed25519 -f ~/.ssh/aws-wp -C "aws-wp"
aws ec2 import-key-pair \
--region ap-northeast-1 \
--key-name aws-wp \
--public-key-material fileb://~/.ssh/aws-wp.pubキーペアはリージョンごとの資源です。東京リージョンで登録した鍵は、大阪リージョンのインスタンス作成画面には出てきません。別のリージョンでも使うなら、同じ公開鍵をそのリージョンにもインポートします。
SSHで接続する
秘密鍵の権限を絞る
macOSやLinuxでは、秘密鍵のファイルを自分だけが読める権限にしないと、SSHが「UNPROTECTED PRIVATE KEY FILE」と警告して鍵の使用を拒否します。
chmod 400 ~/.ssh/aws-wp.pemWindowsのOpenSSHでも同じ警告が出ます。その場合は、ファイルのプロパティのセキュリティ設定で継承を無効にし、自分のユーザーだけに読み取りの権限を残します。
AMIごとのユーザー名
ユーザー名を間違えると、鍵が正しくても接続を拒否されます。代表的なAMIの既定のユーザー名は次のとおりです。
- Amazon Linux：
ec2-user - Ubuntu：
ubuntu - Debian：
admin - Red Hat Enterprise Linux：
ec2-user
ほかのAMIでは、AMIの提供元が案内しているユーザー名を確認してください。
ssh -i ~/.ssh/aws-wp.pem ec2-user@203.0.113.10初めて接続するときは、ホスト鍵のフィンガープリントを確認するメッセージが出ます。厳密に確かめるなら、コンソールの「システムログを取得」で起動時に出力されたフィンガープリントと照合してから yes と答えます。
~/.ssh/config で接続を簡略化する
毎回オプションを打つのは手間なので、設定ファイルに書いておきます。
Host wp-prod
HostName 203.0.113.10
User ec2-user
IdentityFile ~/.ssh/aws-wp.pem
IdentitiesOnly yesこれで ssh wp-prod だけで接続できます。IdentitiesOnly yes は、指定した鍵だけを使わせる設定です。手元に鍵がたくさんあると、SSHが順に試している間にサーバー側の試行回数の上限に達し、正しい鍵を試す前に切断されることがあり、それを防ぎます。
接続できないときの確認
エラーメッセージによって原因の場所が違います。メッセージを読んでから、可能性の高い順に確認します。ssh -v を付けて実行すると、どの段階で止まっているかが詳しく表示されます。
Connection timed out（応答が返ってこない）
通信がサーバーまで届いていない状態です。
- セキュリティグループ：22番ポートのインバウンドルールで、送信元に自分の現在のIPが含まれているか。自宅や外出先でIPが変わると、以前は入れたのに急にタイムアウトするようになります。
- パブリックIP：インスタンスを停止・再開すると、自動割り当てのパブリックIPは変わります。接続先のIPがコンソールの表示と一致しているか確認します。
- ルートテーブルとネットワークACL：パブリックサブネットのルートテーブルにインターネットゲートウェイへの経路があるか、ネットワークACLで22番や戻りの通信を拒否していないかを確認します。
Permission denied (publickey)
サーバーまで届いているが、認証に失敗している状態です。
- ユーザー名：AMIに合ったユーザー名か。
- 鍵の取り違え：インスタンスの詳細に表示されているキーペア名と、使っている秘密鍵が一致しているか。
- サーバー側の権限：サーバーの
~/.sshやauthorized_keysの所有者や権限を変えてしまうと、SSHが鍵を読まなくなります。この場合は後述の復旧方法でファイルを直します。
Host key verification failed
同じIPに別のインスタンスが割り当てられたなどの理由で、以前記録したホスト鍵と一致しない状態です。インスタンスを作り直したと分かっている場合だけ、古い記録を消して接続し直します。心当たりがないのに出た場合は、接続先を確認してください。
ssh-keygen -R 203.0.113.10鍵を追加・入れ替える
担当者ごとに鍵を分けたいときや、鍵を入れ替えたいときは、サーバーの authorized_keys を直接編集します。入れ替えるときは、次の順番を守ると締め出しを防げます。
- 新しい公開鍵を
~/.ssh/authorized_keysに1行追加する - 今の接続を切らずに、別の端末から新しい鍵で接続できることを確かめる
- 確認できてから古い公開鍵の行を削除する
編集の前には authorized_keys のコピーを取っておきます。退職者や不要になった端末の鍵は、その行を消すだけで無効にできます。複数人で使うサーバーでは、誰の鍵か分かるよう、公開鍵の末尾のコメントに名前を入れておくと管理しやすくなります。
秘密鍵をなくしたときの復旧
秘密鍵を失っても、インスタンスの中身を失ったわけではありません。次の方法で新しい公開鍵を登録し直せます。
- EC2 Instance Connect：AWSのAPIを通じて一時的な公開鍵をインスタンスに送り、短い時間だけその鍵で接続できるようにする仕組みです。対応するパッケージが入ったAMI（Amazon Linux 2023 や最近のUbuntuなど）で使えます。コンソールから接続する場合は、セキュリティグループでEC2 Instance Connect の送信元からの22番を許可しておく必要があります。
- Session Manager：インスタンスにSSMエージェントと必要な権限のIAMロールがあれば、SSHを使わずにブラウザやCLIからシェルを開けます。
- ボリュームを付け替える：上の2つが使えない場合は、インスタンスを停止し、ルートボリュームを別のインスタンスにアタッチして
authorized_keysを編集し、元に戻します。作業の前にスナップショットを取っておきます。
接続できたら新しい公開鍵を authorized_keys に追加し、古い鍵の行を削除します。こうした事態に備えて、普段からSession Managerを使える状態にしておくと、SSHのポートを閉じた運用にも移れます。
まとめ
- AWSは公開鍵だけを保持し、初回起動時に
authorized_keysへ書き込む。秘密鍵は再ダウンロードできない。 - LinuxならED25519が扱いやすい。手元で作った鍵をインポートすれば、秘密鍵がネットワークを通らない。
- 秘密鍵は自分だけが読める権限にし、AMIに合ったユーザー名で接続する。
- タイムアウトはネットワーク、Permission denied は認証の問題。エラーで切り分ける。
- 鍵の入れ替えは追加・確認・削除の順で行い、紛失時は Instance Connect か Session Manager で復旧する。