EC2 に ssh できなく、ルードデバイスの EBS を他 EC2 からレスキューした。
この記事で伝えたいのは
EBS を別の EC2 にアタッチして調査するのは面倒じゃないよ！
ってこと。
私が ssh できなかった原因は、 /home がブロックデバイスの EBS に対してリンクされていて、 EC2 の停止により EBS がデタッチされてしまい、 /home が消失してしまった。（自動マウントの設定がされていなかったため）
そのため、ssh をしても Permission denied (publickey). で弾かれていた。
そもそも
再起動、停止では動作が異なる。
再起動だとマウントしたボリュームは外れないので、今まで気づかなかった。
上記には書いていないけど、 再起動だと mount は保持される。
調査…
- 22番ポートが開いているか
$ telnet 192.0.2.1 22で Connected になるか。（IPは仮）
今回私の事象は22番ポートは問題ないので Connected になった。 - ssh をデバッグする
ssh -vvv 192.0.2.1 22でどのようなデバッグがでるか。
今回私の事象は証明書を読み込めていない感じだった（詳細は忘れた）
以上から /home の中を見てみないとわからんという話になった。
めんどうだなーと最初は思っていたが、やってみたら意外にそうでもなかった。
スポンサーリンク
やったこと
- 対象のEC2（以下、対象EC2） をストップ
- 対象EC2 のルートデバイスのボリュームをデタッチする
- デタッチしたボリュームからスナップショット作成
- スナップショットから EBS を作成（以下、対象EBS）
- 調査用の EC2 （以下、調査用EC2）を作成する
- 調査用EC2 に 対象EBS をブロックデバイスとしてアタッチする
- 調査用EC2 を起動して 対象EBS を mount する
- 対象EBS 内の問題点を修正する
- 調査用EC2 を停止して 対象EBS をデタッチする
- 対象EC2 のルートデバイスに 対象EBS をアタッチする
- 対象EC2 を起動して事象が解消されれば成功
一箇所躓いたのが、ルートデバイスとしてアタッチする方法が分からないかったところ。以下に対応方法はまとめておいた。
さいごに
上記のように単純に外して、付ける。
ただそれだけなので、めんどくさいと躊躇している暇があればとっととやったらすぐ終わるものだった。
