パーミッション変更をミスってEC2に入れなくなった時の対処方法

EC2で /（ルート） のパーミッションを変更した（700等）場合、ec2-userによるログインができなくなります。
さらに、
「Permission denied (publickey) 」というエラーになってしまい結構原因が気づきにくいです。

以下、/（ルート） のパーミッションを変更したときの動きです。

まずは、ssh でログイン

$ ssh -i ./keys/key_001.pem [e-mail]


ログイン成功すると↓

Last login: Wed Mar 18 09:01:15 2015 from　XXXXXXXXXXXXXXXXXXXXX

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

[ec2-user@ip-172-31-5-XXX ~]

そして、問題のコマンドを実行！

$ sudo chmod 700 /


【注意】この状態で、セッションが切れると後戻りできなくなります！

さて、この状態でどうなるか別コンソールを立ち上げてログインしてみましょう。

$ ssh -i ./keys/key_001.pem [e-mail]
Permission denied (publickey).

パーミッションエラーになりましたね

---

それでは、ここから間違えて/（ルート）のパーミッションを変更してしまってコンソールに入れなかったときにどうすれば良いか記載します。

AWSコンソールにログインします。
EC2インスタンスの管理画面で適当なマイクロインスタンスを新規で立ち上げます。

　

入れなくなったEC2インスタンスを停止して、アッタッチされている vol-06328c4c　をデタッチします。
（Actions →　Detach Volueme）

　　
　　

デタッチが完了した後、新規で立ち上げたマイクロインスタンスに
vol-06328c4c　を アタッチします。
（Actions →　Atatach Volueme）

---

新しいインスタンスを立ち上げログインします。
$ ssh -i ./keys/key_001.pem [e-mail]


アタッチしたボリュームをマウントします。
$ sudo mkdir /mnt/recovery_ec2
$ sudo mount /dev/xvdf1 /mnt/recovery_ec2


マウントしたディレクトリのパーミッションを変更します。
$ sudo chmod 555 /mnt/recovery_ec2/


続いて、新しく作ったマイクロインスタンスを停止して、vol-06328c4cをデタッチ。そして、元のEC2インスタンス（復元したいインスタンス）にvol-06328c4cをアタッチします。

インスタンスを立ち上げログインすると・・・

Last login: Wed Mar 18 09:01:15 2015 from　XXXXXXXXXXXXXXXXXXXXX

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

[ec2-user@ip-172-31-5-XXX ~]

無事にログインできるようになりました！！

---

ちなみに、今回は、 chmod 700 / という普通ではやらないようなことを意図的にしましたが、以下のようなシェルを書いてしまった場合同様のことが発生してしまいます。

#!/bin/sh
dir=${test_dir}
file_name=${test_filename}

hoge hoge (←適当な処理）
hoge hoge (←適当な処理）

sudo chmod 700 ${dir}/{file_name}
echo "AAAAA" >> ${dir}/{file_name}

${test_dir} と ${test_filename} が NULL になるようなパターンが存在した場合
sudo chmod 700 ${dir}/{file_name}
↓
sudo chmod 700 /
となり、上記と同じ現象が発生してしまいます。

シェルは結構お手軽に作ってしまうこともあり、NULLチェック等忘れがちで思わぬところで最悪の事態が発生してしまうかもしれません。