Linux(Amazon Linux、CentOS、Ubuntuなど)にSSH公開鍵認証でログインできない状況を防ぐ.sshの権限・所有者を修復・復旧するシェルスクリプト(バッチ処理プログラム)、AWSのEC2インスタンスでSSHでログインできなくなった場合の対処法
Linux(Amazon Linux、CentOS、Ubuntuなど)にSSH公開鍵認証でログインできない状況を防ぐ.sshの権限・所有者修復シェルスクリプト(バッチ処理プログラム)、AWSのEC2インスタンスでSSHでログインできなくなった場合の対処法
ssh_auth_owner_setting
AWSなどのパブリッククラウドサービスで手軽にネットワーク・サーバ環境を作ることができるようになったことでセキュリティ対策も重要性を増してきました。
AWSの例を上げるとEC2でLinuxインスタンスを作成した際のデフォルトのログイン方法は予め作成していたキーペア(公開鍵認証)で行います。
公開鍵認証はID・パスワードによる認証に比べて秘密鍵を持っていないとログイン出来ないため安全ですが注意点もあります。
注意点の一つとしてSSHに使用する公開鍵ファイルなどの権限と所有者が適切でないとログインできなくなるということが挙げられます。
何も作業を指定なければ変更されることのない権限と所有者ですが、ユーザディレクトリ内のディレクトリの権限・所有者の一括処理などで意図せずに変更されてしまうこともあります。
もし、そのことに気づかずにログアウトして再度ログインしようとしても権限・所有者が違うため二度とログインできないという事態が発生します。
今回は公開鍵認証のSSHでログインできない事態を防ぐ、権限・所有者設定を適切な状態に保つ.sshの権限・所有者修復シェルスクリプト(バッチ処理プログラム)を備忘録として記載します。
Linux(Amazon Linux、CentOS、Ubuntuなど)にSSH公開鍵認証でログインできない状況を防ぐ.sshの権限・所有者を修復・復旧するシェルスクリプト(バッチ処理プログラム)、AWSのEC2インスタンスでSSHでログインできなくなった場合の対処法
.sshの権限・所有者修復シェルスクリプト(バッチ処理プログラム)
.sshの権限・所有者修復スクリプトの内容は連想配列にユーザディレクトリと所有者情報を持たせて、各ユーザディレクトリ毎にSSHの適切な権限と所有者情報を設定するというものです。
vim ssh_auth_owner_setting.sh
#!/bin/bash
#連想配列を定義する
declare -A USERS
#定義した連想配列に対してキーをユーザディレクトリ名、値を所有者情報として権限修復したいユーザごとに設定する。
USERS["/root"]="root:root"
USERS["/home/magtranetwork"]="magtranetwork:magtranetwork"
#連想配列から１つずつ要素を取り出して処理する。
for USER_DIR in ${!USERS[@]}; do
#ユーザディレクトリをキーに所有者情報を取り出す。
OWNER=${USERS[${USER_DIR}]}
#.sshに適切な権限を付与する。
chmod 700 /${USER_DIR}/.ssh
chmod 600 /${USER_DIR}/.ssh/*
#.sshに適切な所有者を設定する。
chown ${OWNER} -R /${USER_DIR}/.ssh
chown ${OWNER} -R /${USER_DIR}/.ssh/*
done
使用例
/etc/rc.d/rc.localなどLinux起動時に実行されるファイルに上記スクリプトの実行を記述することをおすすめします。
これにより誤って.sshディレクトリ内の権限設定を変えてしまってもLinux起動時に権限・所有者を修復することができます。
CentOS7でも下記のように実行権限を付与することで/etc/rc.d/rc.localを起動時に実行されるようになります。
chmod u+x /etc/rc.d/rc.local vim /etc/rc.d/rc.local
#!/bin/bash touch /var/lock/subsys/local /bin/bash /root/ssh_auth_owner_setting.sh
AWSのEC2インスタンスでSSHでログインできなくなった場合の対処法
AWS EC2で当記事の対策をする前に権限・所有者の変更でSSH公開鍵認証でログインできなくなった場合の対処法を記載します。
オンプレ、VMware、VirtualBoxのLinuxでは.sshの権限・所有者を変更してしまった際に復旧することは他にログイン方法がないと困難です。
一方でAWS EC2の場合は次の方法で.sshの権限を適切なものに変更して復旧することが可能です。
- ログインできなくなったインスタンスを「A」、復旧用に使用するインスタンスを「B」とする
- 「A」のインスタンスをストップする。
- 「A」のEBSをデタッチする。(ルートボリュームの/dev/xvdaなどのデバイスパスは控えておくこと)
- 「B」を新規に作成して、デタッチした「A」のEBSを追加ディスクとしてアタッチする
- 「B」にSSHでログインして「A」のEBSをマウントする
- 「B」から「A」のEBS内部にあるログインユーザディレクトリの.sshの権限・所有者を適切なものに修復する
- 「.sshの権限・所有者修復シェルスクリプト(バッチ処理プログラム)」を配置し、上記「使用例」のように/etc/rc.d/rc.localに記述する
- 「A」のEBSをアンマウント、デタッチして「A」のインスタンスのルートボリュームとして元のデバイスパスにアタッチする。
- 「A」のインスタンスをスタートする