Как указано в приведенном выше вопросе, у меня есть сервер RHEL 6, который предназначен для доступа по SSH, при этом 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). Это общее для всех пользователей, которые существовали и были созданы на этом экземпляре сервера. Кажется, не имеет значения, определяю ли я путь к домашнему каталогу, когда создаю пользователя, или позволяю по умолчанию взять на себя ответственность и назначить его автоматически.
Я не нашел ничего странного в журнале Secure log или журнале сообщений, только то, что пользователь успешно вошел в систему (что у них есть, но ничего не может сделать без оболочки)
Я надеюсь, что на данном этапе переустановка не потребуется, но на сервере почти нет данных, которые были бы потеряны, если бы это был единственный вариант.
Любая помощь будет очень признательна, так как я искал и пробовал неделю безуспешно.
Редактировать:
Я использовал 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
Мне удалось решить проблему, выполнив команду
for p in $(rpm -qa); do rpm --setperms $p; done
и перезапуск сервера. После перезапуска я не только смог войти в систему как любой созданный пользователь, но и снова смог использовать графический интерфейс. Это указывает на поврежденные права доступа к файлам где-то в системе. Как они испортились, я не знаю, но теперь все работает.
В useradd должен создать домашний каталог, когда передан правильный параметр, и вам не нужно (или не нужно) создавать их вручную. Я предлагаю вам выполнить следующее (в указанном порядке), чтобы правильно удалить и воссоздать вашего пользователя.
userdel -f -r user1
useradd -m user1
ПРИМЕЧАНИЕ: вам не нужно проходить -d вариант, поскольку по умолчанию будет /home/user1 в таком случае.
Единственная проблема, которую я вижу в вашей настройке, - это ваш файл passwd. Попробуйте изменить user1:x:513:517::/home/user1:bin/bash к user1:x:513:517::/home/user1:/bin/bash.
У меня была такая же проблема на машине CentOS 6. Это была проблема с файлами в / home с неверной маркировкой контекстов безопасности SELinux. Один из комментаторов выше, Майкл Хэмптон, сказал, что проверка / var / log / audit / audit log - это правильно. Я последовал его совету и заметил, что здесь возникла проблема с SELinux. Решение, которое исправило это для меня, было:
sudo restorecon -Rv /home
Это рекурсивно восстановит метки контекста безопасности по умолчанию для всех файлов в домашнем каталоге. После этого доступ по ssh по публичному ключу был восстановлен.