Linux、CentOS、Ubuntuなど)にSSH公開鍵認証でログインできない状況を防ぐ.sshの権限・所有者修復シェルスクリプトプログラム、AWSのEC2インスタンスでSSHでログインできなくなった場合の対処法ssh_auth_owner_settingAWSなどのパブリッククラウドサービスで手軽にネットワーク・サーバ環境を作ることができるようになったことでセキュリティ対策も重要性を増してきました。AWSの例を上げるとEC2でLinuxインスタンスを作成した際のデフォルトのログイン方法は予め作成していたキーペア(公開鍵認証)で行います。公開鍵認証はID・パスワードによる認証に比べて秘密鍵を持っていないとログイン出来ないため安全ですが注意点もあります。注意点の一つとしてSSHに使用する公開鍵ファイルなどの権限と所有者が適切でないとログインできなくなるということが挙げられます。何も作業を指定なければ変更されることのない権限と所有者ですが、ユーザディレクトリ内のディレクトリの権限・所有者の一括処理などで意図せずに変更されてしまうこともあります。そのことに気づかずにログアウトして再度ログインしようとしても権限・所有者が違うため二度とログインできないという事態が発生します。適切な状態に保つ.sshの権限・所有者修復シェルスクリプトプログラムを備忘録として記載します。Linux、CentOS、Ubuntuなど)にSSH公開鍵認証でログインできない状況を防ぐ.sshの権限・所有者修復シェルスクリプトプログラム、AWSのEC2インスタンスでSSHでログインできなくなった場合の対処法.sshの権限・所有者修復シェルスクリプトプログラム.sshの権限・所有者修復スクリプトの内容は連想配列にユーザディレクトリと所有者情報を持たせて、各ユーザディレクトリ毎にSSHの適切な権限と所有者情報を設定するというものです。USERS#定義した連想配列に対してキーをユーザディレクトリ名、値を所有者情報として権限修復したいユーザごとに設定する。USERS[&quot;/root&quot;]=&quot;root:root&quot;USERS[&quot;/home/mag4j&quot;]=&quot;mag4j:mag4j&quot;#連想配列から1つずつ要素を取り出して処理する。#ユーザディレクトリをキーに所有者情報を取り出す。#.sshに適切な権限を付与する。#.sshに適切な所有者を設定する。/${USER_DIR}/.ssh/*done使用例/etc/rc.d/rc.localなどLinux起動時に実行されるファイルに上記スクリプトの実行を記述することをおすすめします。これにより誤って.sshディレクトリ内の権限設定を変えてしまってもLinux起動時に権限・所有者を修復することができます。CentOS7でも下記のように実行権限を付与することで/etc/rc.d/rc.localを起動時に実行されるようになります。EC2で当記事の対策をする前に権限・所有者の変更でSSH公開鍵認証でログインできなくなった場合の対処法を記載します。オンプレ、VMware、VirtualBoxのLinuxでは.sshの権限・所有者を変更してしまった際に復旧することは他にログイン方法がないと困難です。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」のインスタンスのルートボリュームとして元のデバイスパスにアタッチする。EC2上にシステムを構築する際には最適な選択肢です。EC2はクラウド上にサーバを素早く用意し柔軟に操作できることが特徴のクラウドサービスです。