EC2にログインできなくなったので別インスタンスからEBSのボリュームをマウントして復旧させた

2025.09.07

 鍵を消してしまってEC2にログインできなくなったプライベートでWordPressサーバーとして起動しているEC2を持ってるんですが、長らくメンテナンスも何もしておらず、ログインすらしてませんでした。
たまたま気が向いたんでちょっとくらいメンテするかなと思い、sshで入ろうとしたら鍵で拒否されて入れない。手元には鍵がいくつかあってどれか分からない。持ってる限りの鍵でログインを試みたけどログインできない。どっか変なところに置いちゃったんだろうか。一縷の望みをかけてローカルPC内を検索して探して見たけど、無い。
長い間ログインしておらず、その間に何度もPCを乗り換えてるうちに消えてしまったんだろうか。
まぁssh繋げなくてもEC2なら色々接続する手段あるし問題ない。

...あれ、OSがUbuntuでSSMエージェントが入ってないからセッションマネージャは繋げない。EC2シリアルコンソールもつなげない。EC2 Instance Connectも繋がってくれないじゃん😢。
う、うん、まぁとりあえずサーバー内のデータを引っこ抜ければいい。EBSのスナップショット取ってAMI作って、それで新規インスタンス立ち上げてログインしてみよう...うーん、なぜかだめ（多分なんかやり方悪い）。

じゃあユーザデータからauthorized_keysに鍵書いてみ...うーんこれもだめ（多分これもなんかやり方悪かった）
「あれ？これｵﾜﾀ＼(^o^)／？」
こうなったら仕方ない。別インスタンス立ち上げてそいつからディスクマウントするというくっそめんどくさい原始的な手段で別の鍵を書き込んでsshログイン自体を復旧させようと思ってやった記録。
 1.問題のインスタンスを停止EC2コンソールで問題のインスタンスを停止
 2.ルートボリュームの情報を確認インスタンスの詳細 → ストレージタブ

ルートデバイス名（通常/dev/sda1）とボリュームIDをメモ
 3.ボリュームをデタッチEC2コンソール → ボリューム

該当ボリュームを選択

アクション → ボリュームのデタッチ
 4.レスキューインスタンスを作成同じAZで新しくレスキューインスタンスを起動。

レスキュー対象のOSがubuntuなので一応ubuntuにしておく。
インスタンスは何でもいいのでmicroで。

キーペアを作ってますが、レスキューインスタンスにログインできれば何でもいいです。

sshには入れるようにしておきます。

レスキューのために一時的に使い、作業が終わったら消すのでセキュリティグループとかはまぁ適当に。
インスタンスを起動 を押して起動。
 5.公開鍵を作成ローカルで鍵を作ります。

			ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

秘密鍵id_rsaと公開鍵id_rsa.pubができます。
 6.問題のボリュームをアタッチEC2コンソール → ボリューム

デタッチしたボリュームを選択

アクション → ボリュームのアタッチ

レスキューインスタンスを選択

デバイス名: /dev/xvdfにでもしておきます
 7.レスキューインスタンスで鍵を追加レスキューインスタンスを起動しsshで接続。

			# レスキューインスタンスにSSH接続
ssh -i {レスキューインスタンス作成で作った鍵} ubuntu@レスキューインスタンスIP

レスキュー対象のボリュームを確認しておきます。

			$ sudo lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0          7:0    0 27.6M  1 loop /snap/amazon-ssm-agent/11797
loop1          7:1    0 73.9M  1 loop /snap/core22/2045
loop2          7:2    0 49.3M  1 loop /snap/snapd/24792
nvme0n1      259:0    0    8G  0 disk
├─nvme0n1p1  259:3    0    7G  0 part /
├─nvme0n1p14 259:4    0    4M  0 part
├─nvme0n1p15 259:5    0  106M  0 part /boot/efi
└─nvme0n1p16 259:6    0  913M  0 part /boot
nvme1n1      259:1    0    8G  0 disk      <=== アタッチしたボリューム
└─nvme1n1p1  259:2    0    8G  0 part      <=== レスキュー対象のパーティション

マウントします。

			$ sudo mount /dev/nvme1n1p1 /mnt/rescue

ディスクが見えるようになりました。

			$ cd /mnt/rescue
$ ls
bin   dev  home        lib    lost+found  mnt  proc  run   srv  tmp  var
boot  etc  initrd.img  lib64  media       opt  root  sbin  sys  usr  vmlinuz

 8.authorized_keysを修正5.で作成した公開鍵をauthorized_keysに追加。

			sudo cat >> /mnt/rescue/home/ubuntu/.ssh/authorized_keys << EOF
{5.で作成した公開鍵}
EOF

一応権限も確認しときましょう。

			$ cat /mnt/rescue/etc/passwd　# UserIDの確認
...
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
$ cat /mnt/rescue/etc/group  # GroupIDの確認
...
ubuntu:x:1000:    

			$ sudo chmod 600 /mnt/rescue/home/ubuntu/.ssh/authorized_keys
$ sudo chown 1000:1000 /mnt/rescue/home/ubuntu/.ssh/authorized_keys
$ ls -l /mnt/rescue/home/ubuntu/.ssh/authorized_keys
-rw------- 1 ubuntu ubuntu 1132 Sep  7 02:51 /mnt/rescue/home/ubuntu/.ssh/authorized_keys

作業完了。umount。

			sudo umount /mnt/rescue

 9.ボリュームを元に戻すレスキューインスタンスからボリュームをデタッチ。

元のインスタンスにアタッチ（デバイス名：/dev/sda1）

 10.インスタンスを起動してログイン確認復旧対象のインスタンスを起動してsshでログインしてみます。

			% ssh -i ~/.ssh/id_rsa ubuntu@{問題のインスタンス}
Welcome to Ubuntu 
....
$ ubuntu@ip-xxx-xxx-xxx-xxx:~$

無事に入れました！
 まとめEC2に入れなくなってどうしようもないときの参考にどうぞ。

Amazon Linux使っとけばデフォルトで SSM Agent が入っててセッションマネージャ繋げるのでこんな面倒な目に遭わずに済んだんだけど🥺