サーバーで証明書の設定作業を行っていた際に.sshディレクトリの権限を変更した所、サーバーに入れなくなってしまいました。
いわゆるパーミッション事故というやつです。
今回は自戒の念も込めて、パーミッション事故の原因と解決策をまとめました。
状況説明
AWS EC2インスタンスで仮想サーバーを構築。
公開鍵認証方式でSSH接続を行っていた。
サーバーに入れなくなった理由
.sshディレクトリの権限は700でなければならないと決まっています。
また、秘密鍵（id_rsa ファイル）の権限についても、権限が 600 か 400 になっている必要があります。
この状態でなければ、鍵が安全な状態でないと判断され鍵認証での接続が拒否されるようです。
このことを知らなかったり、知っていてもうっかり権限を変更してサーバーのセッションが切れてしまうとサーバーに入ることができなくなります。
700や600はディレクトリやファイルの権限範囲を表しています。
数字の組み合わせによって誰がどの操作まで可能かを管理しています。
- 所有者
- グループ
- その他ユーザー
においてそれぞれが表のように権限を設定します。
| 数値 | 権限 | 内容 |
|---|---|---|
| 0 | — | 権限なし |
| 1 | –x | 実行できる |
| 2 | -w- | 書き込みできる |
| 3 | -wx | 書込・実行できる |
| 4 | r– | 読み込みできる |
| 5 | r-x | 読込・実行できる |
| 6 | rw- | 読込・書込みできる |
| 7 | rwx | 読込・書込・実行できる |
3桁目の数字が所有者、2桁目の数字がグループ、1桁目の数字がその他ユーザーの権限を表しています。
例えば、744であれば所有者は全ての権限を持っており、グループとその他ユーザーは読み込みのみ可能です。
今回の例で言えば、.sshディレクトリは所有者のみが読込・書込・実行できる状態になっていなければならず、その他ユーザーは権限なしの状態でなければなりませんでした。
参考サイト↓
解決策
今回はAWS EC2インスタンスを利用していた為、下記の方法で復旧作業を行いました。
1,一時的に利用するインスタンスを作成
2,接続できなくなったインスタンスのボリュームをデタッチ（ボリューム名はメモしておく）
3,一時作成したインスタンスに2,でデタッチしたボリュームをアタッチ
4,一時作成したインスタンスに接続し、適当な名前でディレクトリを作成
5,作成したディレクトリにてアタッチしたボリュームをマウント
6,マウントしたディレクトリ内で変更してしまった.sshディレクトリの権限を700に戻す
7,一時作成したインスタンスのボリュームをデタッチ
8,接続できなくなっていたインスタンスに再度ボリュームをアタッチ
以上で誤って変更してしまった.sshディレクトリの権限を700に戻すことができ、公開鍵認証が可能な状態に戻りました。
ボリュームとはEC2インスタンスのストレージのこと。
今回はこのボリュームを接続可能な状態にして.sshディレクトリの権限を修正して元に戻している。
※詳細はリンクURLにて画像付きで説明があるので参考にして下さい
※EC2サービス サイドバーの『Elastic Clock Store』にてボリューム一覧を確認することができます。
ボリュームのアタッチ・デタッチ 注意点
ボリュームのアタッチをする際にはデバイス名を設定する必要があります。
こちらの値が正しくなければ意図した修正ができない為、修正がうまくいかない場合は確認して下さい。
権限の変更にはくれぐれもご注意を。。
