0

As the question above states, I have a RHEL 6 server that is designed for SSH access, with root unable to login through SSH by design. When I am at the server locally I can login as root, but only as root. If I try to log in as a user the screen quickly flashes a message reading:

Last Login: Mon Aug 24 08:24:52 on tty1
no directory: /home/user1!
logging in with home="/"
login: no shell: Permission denied

I am getting the no shell because there is no shell in /.

Now what is really confusing to me though is that the home directory does indeed exist, and contains a valid shell, and is permissioned right from what I can tell (755). This is common for all users that existed and have been created on this server instance. It seems to matter not if I define a path to the home directory when I make a user or let the default take charge and assign it automatically.

I have not found anything strange in the Secure log or messages log, only that the user successfully logged in (which they have, but can't do anything without a shell)

I am hoping to not need to reinstall at this point, but there is almost no data on the server that would be lost if that is the only option.

Any help would be very much appreciated as I have searched and tried for a week now with no luck.

Edit:

I used the useradd user1 command to originally add the user, when that resulted in the problems above I used

mkdir /home/user1 && useradd user1 -d /home/user1 && chown -R user:user1 /home/user

When I run the cat /etc/passwd | grep user1 command I get:

user1:x:513:517::/home/user1:bin/bash

and when I run the ls -l /home command the entry for that user is:

drwxr-xr-x. 4 user1 user1 4096 Aug 19 17:03 user1
WxFisch
  • 11
  • 1
  • 5
  • What commands did you use to add users? – william Aug 24 '15 at 13:03
  • 2
    If you provide the output of 'cat /etc/passwd | grep user1' and 'ls -l /home' someone here will be able to help. – Arul Selvan Aug 24 '15 at 13:04
  • 1
    Why do you think `/` or your home directory need to "contain a shell"? The shell defined in `/etc/passwd` for your user (most likely `/bin/bash`) needs to be existing and executable. – Sven Aug 24 '15 at 13:10
  • Sven, I understand that the shell is defined in `/etc/passwd`, however I think the root problem that I am having is that the OS seems to not be able to find the home directory even though it exists and the user has permission to access it, as well as `/bin/bash` as is listed in the `/etc/passwd` file – WxFisch Aug 24 '15 at 14:23
  • Check your `/var/log/audit/audit.log`. – Michael Hampton Aug 24 '15 at 17:16

4 Answers4

1

I was able to fix the problem by running the command

for p in $(rpm -qa); do rpm --setperms $p; done

and restarting the server. Once it restarted not only was I able to log in as any user that had been created I was able to again use the GUI as well. This points to corrupted file permissions somewhere on the system. How they became corrupted I do not know, but it all now works.

WxFisch
  • 11
  • 1
  • 5
0

The only issue I can see with your setup is in your passwd file. Try changing user1:x:513:517::/home/user1:bin/bash to user1:x:513:517::/home/user1:/bin/bash.

william
  • 146
  • 4
  • I fixed that and it still shows the same symptoms, root can log on and no one else can get a shell to open. – WxFisch Aug 25 '15 at 12:08
  • Does `/bin/bash` exist? Try running `su user1 -c /bin/bash` and `su user1 -c /bin/sh`. – william Aug 25 '15 at 14:35
  • `/bin/bash` does exist, when I run the `su user1 -c .bin/bash` I get the following: `su: /bin/bash: Permission denied` It may be of interest that the permission on `/bin/bash` are: `-rwxr-x-r-x. 1 root root 938736 Apr 23 2012 bash` – WxFisch Aug 25 '15 at 14:50
  • I just saw your comment about powering it off. If that's all you did and it's not working now, then it might be because of corrupted files on the drive. There's an article (http://www.tldp.org/LDP/LG/issue52/okopnik.html) in which the author uses `strace` to try to track down issues, but at that point it may be faster to just reinstall since you don't have much data on the server. – william Aug 25 '15 at 15:03
  • That is kind of where I was thinking the problem lies, but I wanted to ask for some advice from the more experienced out there before I go to management and tell them I need access to the License information again as that is somewhat a pain – WxFisch Aug 25 '15 at 17:48
  • Ah, I was thinking it would be just an easy reinstall. But yeah, generally if you didn't update or modify any of the software `power off -> power on -> something's broken` means a hardware issue. – william Aug 25 '15 at 18:48
  • The link you posted helped to point me in the right direction of corrupted file permissions. However not wanting to spend hours upon hours manually pouring through the permissions and comparing them I was able to find a small script that sets the permissions to what is in RPM, which was able to fix my problem. – WxFisch Sep 01 '15 at 19:16
0

The useradd should create the home directory when correct option is passed and you don't (or shouldn't) have to create them manually. I suggest you execute the following (in the order listed) to remove and recreate your user properly.

userdel -f -r user1
useradd -m user1

NOTE: you don't have to pass the -d option since the default will be /home/user1 in this case.

Arul Selvan
  • 1,338
  • 12
  • 11
  • This is how I originally added the users to the server, and it was working fine for a while (a few months). It is only recently after powering off the server, racking it in a different location, and powering it back on, that I am having these problems. – WxFisch Aug 25 '15 at 14:52
0

I just had this same issue on a CentOS 6 machine. This was an issue with files in /home having mislabeled SELinux security contexts. One of the commenters above, Michael Hampton, who said to check /var/log/audit/audit log was spot on. I followed his advice and noticed that there was an SELinux issue going on here. The solution that fixed it for me was:

sudo restorecon -Rv /home

That will recursively restore default security context labels on all files in the home directory. After that, ssh access via publickey was restored.

nazwadi
  • 1
  • 1