2026年6月2日

AWS EC2のSSH接続方法と鍵ペア管理｜接続できないときの確認と鍵を紛失したときの復旧

VPS・クラウド

AWS の EC2 に SSH で接続するには、インスタンスの起動時に指定した鍵ペアの秘密鍵を使い、OS ごとに決まったユーザー名で ssh -i 秘密鍵ユーザー名@IPアドレス を実行します。接続できないときは、エラーの種類から「ネットワークで止まっているのか、認証で止まっているのか」を見分けると原因を絞れます。この記事では、鍵ペアの作り方と取り込み方、接続の手順、エラー別の確認方法、鍵を紛失したときの復旧と、鍵を入れ替える手順までを説明します。

鍵ペアの仕組み

EC2 の鍵ペアは、公開鍵と秘密鍵の組です。AWS が保管するのは公開鍵だけで、インスタンスの初回起動時に、その公開鍵がログインユーザーの ~/.ssh/authorized_keys に書き込まれます。

ここから分かる大事な点が3つあります。

秘密鍵は作成時に一度しかダウンロードできません。 AWS 側からは取り出せないため、紛失すると同じ鍵では接続できなくなります。
**AWS のコンソールで鍵ペアを削除しても、インスタンスの authorized_keys からは消えません。** 起動済みのインスタンスへのアクセスを止めたいときは、インスタンス内のファイルを編集します。
鍵ペアはリージョンごとに管理されます。 東京リージョンで作った鍵ペアは、別のリージョンのインスタンス起動時には選べません。

鍵の種類は RSA と ED25519 を選べます。Linux のインスタンスなら ED25519 が鍵も短く扱いやすい選択です。Windows のインスタンスでは、管理者パスワードの復号に RSA が必要なため、ED25519 は使えません。

鍵ペアを用意する

AWS で作る

コンソールの EC2 の画面から鍵ペアを作成できます。形式は、OpenSSH で使う .pem と、PuTTY で使う .ppk から選びます。AWS CLI の場合は次のとおりです。

aws ec2 create-key-pair \
  --key-name web-prod-2026 \
  --key-type ed25519 \
  --key-format pem \
  --query 'KeyMaterial' \
  --output text > ~/.ssh/web-prod-2026.pem

chmod 400 ~/.ssh/web-prod-2026.pem

手元で作った鍵を取り込む

秘密鍵を一度も外に出したくない場合は、手元で鍵を作り、公開鍵だけを AWS に登録します。パスフレーズを付けておくと、秘密鍵のファイルが漏れても、すぐには使われにくくなります。

ssh-keygen -t ed25519 -f ~/.ssh/web-prod-2026 -C "web-prod-2026"

aws ec2 import-key-pair \
  --key-name web-prod-2026 \
  --public-key-material fileb://~/.ssh/web-prod-2026.pub

AWS CLI v2 では、ファイルの中身を渡すときに fileb:// を使います。file:// だとエラーになることがあります。

SSH で接続する

接続には次の3つがそろっている必要があります。

インスタンスにパブリック IP（または Elastic IP）があり、インターネットゲートウェイへの経路があること
セキュリティグループの受信ルールで、TCP 22番が自分の IP から許可されていること
起動時に指定した鍵ペアの秘密鍵と、正しいユーザー名

ユーザー名は AMI によって異なります。よく使うものは次のとおりです。

Amazon Linux: ec2-user
Ubuntu: ubuntu
Debian: admin
RHEL: ec2-user

これ以外の AMI や、Marketplace の AMI では別の名前のことがあるため、AMI の説明を確認してください。

ssh -i ~/.ssh/web-prod-2026.pem ec2-user@203.0.113.10

毎回オプションを打つのが面倒なら、~/.ssh/config に書いておきます。IdentitiesOnly yes を付けると、指定した鍵だけを使うので、手元の鍵が多いときに「試行回数の上限で切断される」問題を避けられます。

Host web-prod
    HostName 203.0.113.10
    User ec2-user
    IdentityFile ~/.ssh/web-prod-2026.pem
    IdentitiesOnly yes

ssh web-prod

セキュリティグループで22番を 0.0.0.0/0（すべての IP）に開けたままにすると、世界中から絶えずログイン試行を受けます。接続元を自分の IP や社内のネットワークに限定し、後で説明する Session Manager などで22番自体を閉じる構成も検討してください。

接続できないときはエラーの種類で切り分ける

ssh -v を付けて実行すると、どこまで進んで止まったかが表示されます。エラーごとに、起きやすい原因を順に挙げます。

Connection timed out（応答が無い）

ネットワークの段階で止まっています。認証の問題ではありません。

セキュリティグループ: 受信ルールに TCP 22番があり、送信元に今の自分の IP が含まれているか。自宅やモバイル回線は IP が変わることがあります。
パブリック IP: インスタンスを停止・起動すると、Elastic IP でないパブリック IP は変わります。コンソールで今の IP を確認します。
サブネットの経路と NACL: パブリックサブネットのルートテーブルにインターネットゲートウェイへの経路があるか、ネットワーク ACL で22番や戻りの通信が拒否されていないか。
インスタンスの状態: ステータスチェックが失敗していないか。OS のファイアウォールで22番を閉じていないか。

Permission denied (publickey)

サーバーには届いていて、認証で拒否されています。

ユーザー名の間違い: Ubuntu に ec2-user で入ろうとしている、などが最も多い原因です。
鍵の取り違え: インスタンスの詳細画面で、起動時に指定された鍵ペアの名前を確認し、手元のファイルと照合します。
秘密鍵のパーミッション: UNPROTECTED PRIVATE KEY FILE! と表示される場合は、chmod 400 で自分だけが読める状態にします。Windows の OpenSSH では、ファイルのプロパティで自分以外のユーザーのアクセス権を外します。

Connection refused

サーバーには届いていますが、22番で待ち受けているプロセスがありません。sshd が停止しているか、ポート番号を変えている可能性があります。

Host key verification failed

同じ IP アドレスに別のインスタンスが割り当てられ、手元の ~/.ssh/known_hosts に記録された鍵と合わなくなったときに出ます。インスタンスを作り直したなど理由が分かっている場合に限り、ssh-keygen -R 203.0.113.10 で古い記録を消します。理由が分からない場合は、接続先が想定どおりかを先に確認してください。

22番を開けずに接続する方法

SSH 鍵の配布や22番の公開を避けたい場合は、AWS の次の機能が使えます。詳細な要件や対応 OS は更新されることがあるため、AWS のドキュメントを確認してください（2026年10月現在）。

Session Manager（Systems Manager）: インスタンスの SSM Agent が AWS に接続する方式で、受信ポートを開ける必要がありません。インスタンスに AmazonSSMManagedInstanceCore などのポリシーを持つ IAM ロールを付け、手元からは aws ssm start-session --target i-0123456789abcdef0 で接続します（Session Manager プラグインが必要）。操作のログを残せる点も利点です。
EC2 Instance Connect: 一時的な公開鍵を短時間だけインスタンスに渡して接続する方式です。IAM の権限で誰が接続できるかを管理できます。
EC2 Instance Connect Endpoint: パブリック IP を持たないプライベートサブネットのインスタンスに、踏み台サーバーなしで接続できます。

秘密鍵を紛失したときの復旧

秘密鍵を再ダウンロードすることはできません。新しい鍵を作り、その公開鍵をインスタンスの authorized_keys に入れる、という方針で復旧します。作業の前に、インスタンスの EBS ボリュームのスナップショット（または AMI）を取っておいてください。

Session Manager や EC2 Instance Connect が使える場合: それで接続し、新しい公開鍵を ~/.ssh/authorized_keys に追記します。最も簡単な方法です。
AWS Systems Manager の自動化を使う: AWSSupport-ResetAccess という自動化ドキュメントで、新しい鍵を設定できる場合があります。対応する条件は AWS のドキュメントで確認してください。
ルートボリュームを別のインスタンスで編集する: インスタンスを停止し、ルートボリュームを切り離して、同じアベイラビリティーゾーンの作業用インスタンスに接続します。マウントしたボリューム上の home/ec2-user/.ssh/authorized_keys に新しい公開鍵を追記し、元のインスタンスに戻して起動します。インスタンスストアのデータは停止で消え、パブリック IP も変わる点に注意してください。

鍵を安全に入れ替える

担当者の異動や、鍵の漏えいが疑われるときは、鍵を入れ替えます。古い鍵を先に消すと自分も締め出されるため、順番が大切です。

新しい鍵ペアを作り、公開鍵をインスタンスの authorized_keys に追記する
今の接続は切らずに、別のターミナルから新しい鍵で接続できることを確かめる
確認できたら、authorized_keys から古い鍵の行を削除する
AWS の鍵ペア一覧からも古い鍵ペアを削除し、手元やチームで共有していた秘密鍵を破棄する

秘密鍵は Git のリポジトリやチャットに置かないでください。チームで共有するより、一人ひとりが自分の鍵を持ち、それぞれの公開鍵を登録するほうが、退職や異動のときに特定の人の鍵だけを外せます。人数が多い場合は、Session Manager と IAM で接続できる人を管理する方法が向いています。

まとめ

鍵ペアの秘密鍵は作成時に一度しか取得できません。手元で作って公開鍵だけを取り込む方法もあります。
接続には、パブリック IP と経路、セキュリティグループの22番、正しい鍵とユーザー名の3つが必要です。
Connection timed out はネットワーク、Permission denied (publickey) は認証の問題です。エラーの種類で調べる場所を分けます。
秘密鍵を紛失したら、Session Manager などで接続するか、ルートボリュームを別のインスタンスで編集して新しい公開鍵を入れます。
鍵の入れ替えは「追加して確認してから古い鍵を消す」の順に行い、22番を閉じられる Session Manager も検討します。