正如上面的问题所述，我有一个专为SSH访问而devise的RHEL 6服务器，root用户无法通过SSHlogin。 当我在本地服务器时，我可以以root身份login，但只能以root用户身份login。 如果我尝试以用户身份login，屏幕会快速闪烁一条消息：
Last Login: Mon Aug 24 08:24:52 on tty1 no directory: /home/user1! logging in with home="/" login: no shell: Permission denied 我得到没有shell，因为没有shell在/ 。
现在我真正感到困惑的是，主目录确实存在，并且包含一个有效的shell，并且从我所知道的（ 755 ）的权限。 对于在此服务器实例上已存在并已创build的所有用户，这是很常见的。 这似乎不是如果我定义一个path到主目录时，我让一个用户或让默认负责和自动分配。
我在安全日志或消息日志中没有发现任何奇怪的事情，只有用户成功login（他们有，但没有一个shell不能做任何事情）
我希望在这一点上不需要重新安装，但是如果这是唯一的select，服务器上几乎没有数据丢失。
任何帮助将非常感激，因为我已经search，并尝试了一个星期，现在没有运气。
编辑：
我使用useradd user1命令最初添加用户，当导致上面我使用的问题
mkdir /home/user1 && useradd user1 -d /home/user1 && chown -R user:user1 /home/user
当我运行cat /etc/passwd | grep user1 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
并重新启动服务器。 一旦它重新启动，我不仅能够以任何已创build的用户身份login，还能够再次使用GUI。 这指向系统上某处损坏的文件权限。 他们如何变得腐败我不知道，但现在一切正常。
我可以看到你的设置唯一的问题是你的passwd文件。 尝试更改user1:x:513:517::/home/user1:bin/bash到user1:x:513:517::/home/user1:/bin/bash 。
当正确的选项被传递时， useradd应该创build主目录，而你不需要（或者不应该）手动创build它们。 我build议你执行以下（按列出的顺序）删除并重新创build用户。
userdel -f -r user1 useradd -m user1
注意：您不必传递-d选项，因为在这种情况下，缺省值将是/home/user1 。