問題の原因
次のようにして、「.hgignore」のような隠しファイルにグループ書き込み権限を追加するつもりでした。
#パスワード /opt # sudo chmod -R g+w .*
問題は、「..」がこのパターンに一致し、RHEL ファイルシステム全体に g+w が設定されていることです。当面の問題は次のとおりです。
- /etc/sudoers は 460 ではなく 440 に設定する必要があり、そのためユーザーは sudo を使用できなくなります。
- 上記と同様のメカニズムでは、SSH アクセスが許可されません。(リモート SSH クライアントは、「ssh_exchange_identification: リモート ホストによって接続が閉じられました」というエラー メッセージを受信します)
質問
リモートでログインする機能を回復するには、サーバーに物理的にアクセスできるユーザーにシステムの修復方法を指示する必要があります。
ここで問題となるのは、機能sshを復元するために、どの重要なファイルとディレクトリの権限を元に戻す必要があるかということです。sudo
「重複として閉じる」に関する注意
質問「chmod -R 777 /」が破壊的なのはなぜですか?再帰的に権限を拡張するとどのような影響があるかについて詳しく説明します。この質問は、より広範な復元と修復を実行できるように、ssh 経由でリモート アクセスを回復する方法についての質問に答えることを目的としています。
答え1
パッケージの一部であるファイルの場合、何が問題なのかを調べるには、
rpm --verify "パッケージ名"
ここで、packagenameは個々のパッケージです。または、「rpm -qa」の出力をループすることもできます。
その後、rpmを使用して次のように修正できるはずです。
rpm --setperm "パッケージ名"
答え2
ssh の問題は、/etc の直下に限定されず、接続しようとしているユーザーの .ssh フォルダに不適切な権限があることにも関係しています。通常、ユーザーの .ssh フォルダは 700、秘密鍵は 600、その他はすべて 644 にする必要があります。
/etc/ssh フォルダは 755、/etc/ssh の下の秘密鍵は 600、その他はすべて 644 である必要があります。
/etc の不正な権限からサーバーを回復するにはどうすればいいですか?
おそらく最も簡単な方法の 1 つは、バックアップから復元することです。バックアップを作成し、復元手順をテストしましたか? :)
復元に使用できるバックアップがない場合は、VM 内に同一のクリーンなシステムをセットアップし、2 つのシステムを比較してサーバーに基づいてホストの権限を修正する必要がある場合があります。
答え3
正常に動作するサーバーがわかっている場合は、そのサーバーで次のようなコマンドを実行すると、復元できる可能性があります。(再帰的なグロブ機能 (zsh) を前提としていますが、代わりに -exec / xargs を指定した find を使用することもできます)。
for i in /etc/**/*; do
perm=$(stat "$i" -c "%a")
ssh root@badServerHostName "chmod $perm $i"
done
除外するサブディレクトリがいくつかあるかもしれないし、追加するかもしれない... Rsyncができればもっと良いだろうのみ権限がありますが、それはできないと思います。
答え4
バックアップがあり、LVM と十分なスペースがある場合は、次の操作を実行できます。
1. バックアップを新しい一時的な lv に復元します (/oldperm の下にマウントします)
2. 次の疑似コードのようなものを実行します。
foreach oldfile in /oldperm/* {
newf = strip "/oldperm" from oldfile
chmod --reference=oldfile newf
}
スペースの問題がある場合に備えて、まず /etc の下にあるすべてのものを部分的に復元することができます。このトリックは、別のファイルをテンプレートとして受け取り、権限に関して引数を一致させる chmod のフラグ --reference に依存しています。
この方法では、ファイルの内容を変更せずに古い権限のみを復元します。