上記の質問にあるように、私は SSH アクセス用に設計された RHEL 6 サーバーを持っていますが、設計上、root は SSH 経由でログインできません。ローカルのサーバーにいるときは、root としてログインできますが、root としてのみログインできます。ユーザーとしてログインしようとすると、画面に次のメッセージがすぐに表示されます。
Last Login: Mon Aug 24 08:24:52 on tty1
no directory: /home/user1!
logging in with home="/"
login: no shell: Permission denied
にシェルがないので、シェルなしが表示されます/。
しかし、私にとって本当に混乱しているのは、ホーム ディレクトリが実際に存在し、有効なシェルが含まれており、私の知る限りでは権限が与えられているということです ( 755)。これは、このサーバー インスタンスに存在し、作成されたすべてのユーザーに共通です。ユーザーを作成するときにホーム ディレクトリへのパスを定義するか、デフォルトに任せて自動的に割り当てるかは問題ではないようです。
セキュア ログやメッセージ ログには何も異常は見つからず、ユーザーが正常にログインした (ログインは成功しているが、シェルなしでは何もできない) ことだけがわかります。
この時点で再インストールする必要がないことを願っていますが、それが唯一の選択肢である場合、サーバー上に失われるデータはほとんどありません。
1 週間検索して試してみましたが、うまくいかなかったので、どんな助けでも大歓迎です。
編集：
最初にユーザーを追加するためにコマンドを使用しましたがuseradd user1、上記の問題が発生したため、
mkdir /home/user1 && useradd user1 -d /home/user1 && chown -R user:user1 /home/user
コマンドを実行すると次のcat /etc/passwd | grep user1結果が得られます:
user1:x:513:517::/home/user1:bin/bash
コマンドを実行すると、ls -l /homeそのユーザーのエントリは次のようになります。
drwxr-xr-x. 4 user1 user1 4096 Aug 19 17:03 user1
答え1
コマンドを実行することで問題を解決できました
for p in $(rpm -qa); do rpm --setperms $p; done
サーバーを再起動しました。再起動すると、作成されたユーザーとしてログインできるだけでなく、GUI も再び使用できるようになりました。これは、システムのどこかでファイル権限が破損していることを示しています。どのように破損したのかはわかりませんが、すべて正常に動作しています。
答え2
あなたの設定で問題と思われるのは、passwd ファイルだけです。
user1:x:513:517::/home/user1:bin/bash
に 変更してみてくださいuser1:x:513:517::/home/user1:/bin/bash。
答え3
正しいオプションが渡されるとホーム ディレクトリが作成useraddされ、手動で作成する必要はありません (または作成すべきではありません)。ユーザーを適切に削除して再作成するには、以下を (記載されている順序で) 実行することをお勧めします。
userdel -f -r user1
useradd -m user1
-d注意: この場合はデフォルトになるため、オプションを渡す必要はありません/home/user1。
答え4
CentOS 6 マシンで同じ問題が発生しました。これは、/home 内のファイルに SELinux セキュリティ コンテキストのラベルが誤って付けられている問題でした。上記のコメント者の 1 人である Michael Hampton が /var/log/audit/audit log を確認するよう言っていたのは、まさにその通りでした。彼のアドバイスに従ってみると、ここで SELinux の問題が発生していることに気付きました。私の場合、この問題を解決した解決策は次のとおりでした。
sudo restorecon -Rv /home
これにより、ホーム ディレクトリ内のすべてのファイルのデフォルトのセキュリティ コンテキスト ラベルが再帰的に復元されます。その後、公開キー経由の SSH アクセスが復元されました。