ssh could not chdir to home directory
 

Hello all, Im seeking a little help on a weird issue. I have a server with about 20 or so users on it. It is SUSE Enterprise Server 10. It's been in production for about 2 years. All of the sudden, one of my users says he is unable to log in. So I checked it out, I logged in as root and tried sshing and su-ing to this user and this is what I get....

Permissions in/on this users home directory are good "drwx------" and owned by the user. I checked /etc/passwd to make sure nothing got screwy in there... Im not sure what else to look at, and not sure what the heck would have changed. Please let me know if I can provide any more output that would help narrow it down. Any help would greatly be appreciated!
Thanks

raises suspicion about the permissions and home of this user. but since the info u provided is rather limited:

can the other 19 users ssh?

does /home/user1 exists? (case sensitive)

check the permission on /home to make sure its owned by root 755

check to make user is not in a block list.
did u install some new packages for security?

possible quick fix:
make a new user and ssh localhost then thru the wan. if all works simply transfer files over to the new user1 home and chown it.

hope this helps.

puzzling
 

Just to narrow the possibilities:

Is this problem unique to that single user, or do the others (or at least a few others) also have this problem?

Is it possible to login at the location of the server into the problematic user account?

Is it the same problem for all login alternatives like SSH, FTP, Telnet, etc.?

If permissions are correct, then the application that provides access is accessing that home directory with the wrong account information. A file system check is probably also a good idea.

Hello, yeah, I guess I wasn't specific enough. Yes it is limited to just this one user. Everyone else can log in just fine. Nothing to "my knowledge" has been installed. The problem is for all login methods for this one user, I used ssh to provide me with output. Like I said in my original post, the permissions are fine for /home (everyone else is able to do their work) and this particular users permissions are fine on his particular directory, 0700 and owned by him.

I realize I could just make a new home dir or recreate the user entirely and restore the data to his directory, but I was hoping to try and fix this and figure out why it happens. Thanks for your replies.

since this is a production box, i would not experiment with it too much but get to quickest solution. you can still keep a copy of the /home/user1 for later experiments.

obviously points to permission.

the most immediate test is simply to set 777 to /home/user1 then as root su - user1. if there is still probs, then there is either a block or user1 name/home directory mismatch.

check whether the home directory is correct.
- /etc/passwd
- bashrc and/or any other file your shell sources
strace the ssh

the fact this is an isolated case (according to your info). I would sus whether this user has been tampering with the files provided the user never had this problem before. check the log both user/root during the time before the error occurred from the user1 machine.

hope this helps.

Hi all...

I found this post because I had the same issue just now. I have a server here at home, I was setting up samba (on my desktop) to auto mount the shared on the server. Server is centos, btw. Desktop is Ubuntu hardy, not that it matters much. On the server, I have disabled root login too. This is the same or similar weird issue...

The share is not mounting, another story though, so I went to ssh into the centos box (actually clarkconnect, but Ive jacked it around quite a bit), anyhow it gave me the same error/issue, but it gave me a bash prompt I have not seen before. The whole thing looked like this after an 'ssh me@host'...

Notice the odd prompt, or at least to me its odd. I actually figured that it was because bash had no profile to go by.

So, I tried a 'su', and it prompted me for the password and let me log in as root, I probably should look a little further in that actually.

Anyhow, It turned out that my permission on my home folder was screwed with. I am quite sure that it was because I used the web admin tool to turn on my /homes in samba. Heres the before and after...

call me paranoid, I replace my name with [ME] in case you haven't figured that out :), anyway note the permission on [ME]

next...
then...
Now everything is back to normal, or at least the way I had it...

Just some info, I look at the .bash_profile and .bashrc right away and nothing was added or taken. I am blaming either samba, or the scripts that was associated with the webmin app. I actually prefer to do this stuff by hand, partly for this reason.

But /home/[me] should have 700 permissions, and be owned by either [me]:[me] or [me]:[users] in CentOS.

was repeat post probably something I did...

Dang it...thats one reason I posted this morning. I will change my permissions....hold please...

Well, when I change my home dir to 700, I get the origianl issue. When I chmod it to 755, it acts fine. Now I need to figure this one out...

But wait a minute, what I keep finding on the net is that default home permissions for CentOS is 755, If I don't figure this out soon, I will bring it up at the next LUG, one of the CentOS team leaders is a member here. Even still, I want to know more...:)

Mine are all 700, and frankly, why would you want other users being able to read your home dir?

Your issue is ownership though, as I posted above.

Edit. I just added a new user under CentOS, and permissions are 700, ownership username:username

I agree, and I found more info where CentOS's default home directory permissions are in fact 700. And your right, I don't want others reading my directory either...And, And, I agree also (with you) it is an ownership issue. Somehow it set my ownership to my GID I think... lets fix it and see... (the 1000 did look a little out of place when I was posting earlier)

Ok...and Thank you...

I did a chmod 700 to my home and then a chown [ME] [ME] and all is well.

Keen eye billymayday, and thanks. This is one reason I love LQ, so I can learn.

oh yeah, so this means that one of my actions, messing with samba, had changed my ownership though...and I wonder if this was way off from the origianl poster then.

Glad to help

So there is a reference here, I ran into the same problem with a different solution.

I'm running Fedora 9 x86_64, and had the same issue. All of my file permisssions are good though. I disabled SELinux with sudo setenforce 0 and was able to log in. (this was messing with my ability to FTP, was otherwise just annoying)

Other people may want to elaborate on a fix, I'm just going to disable SELinux, since this is a personal machine. . .

Just my $0.02

If this had been an SELinux issue, it would simply have meant that the contexts for the home directory had gotten messed up, and a simple restorecon would have fixed things up (or at least should).

For your ftp issue, I'll make two points.

The first is that setenforce is not persistent, so at very least you will either need to disable it permanently or re-enter seenforce 0 each time you boot. If you run gnome, there is a security setting program, otherwise the seting will be in /etc/selinux somewhere.

A better solution (if you like screwdriver solutions over sledgehammers) is to either set your own policies (you need to be reasonably keen here), or you can disable SELinux for sertain actions. Not sure of your directory structure, but here's what I have that looks relevant in /selinux/booleans:
The relative sledgehammer here is to "setsebool -P ftpd_disable_trans 1", but if your issue is just with working with home directories, setting ftp_home_dir may do it for you.

Not sure which ftp daemon you use or if will necessarily work for your situation. I use vsftpd, and here is what's set for me:

I'm just going to disable (permanently), but thank you for posting this for other users who might want to keep it around :)

Similar problem - need help
 

I tried to move /home to different partition and got the following problem when trying to login:

Last login: Thu Jun 4 13:03:08 2009 from *.*.*.*
Could not chdir to home directory /home/[ME]: Permission denied

although permission, SELinux context are exactly the same as the originals.

After this error, system stays at / and lets me in, and no other errors after that. Even su - [ME] does not issue any errors and goes to /home/[ME] directory correctly.

Here are related infos:
lrwxrwxrwx root root system_u:object_r:home_root_t:s0 home -> /app/home
drwxr-xr-x root root system_u:object_r:home_root_t:s0 home_hold


drwx------ [ME] [ME] system_u:object_r:user_home_dir_t:s0 [ME]

Any idea?

What distro are you using?

Try from the commandline and try again, that will confirm or exclude selinux as the source of your problem.

What distro are you using?

On CentOS, correct context for jome directories is user_u:object_r:user_home_dir_t not system_u:object_r:user_home_dir_t

Obviously it's context
 

Distro: Fedora 10

What should be the context of the softlink /home
(It seems that it should not be the same as the original directory's
system_u:object_r:home_root_t:s0 home )

Here is the Security log:

When squirrel mail tries to loging:
SELinux is preventing dovecot (dovecot_t) "read" to home (home_root_t).

Source Context: system_u:system_r:dovecot_t:s0Target
Context: system_u:object_r:home_root_t:s0Target
Objects: home [ lnk_file ]

When: ssh tries to login:
SELinux is preventing sshd (sshd_t) "read" to home (home_root_t).

Source Context: system_u:system_r:sshd_t:s0-s0:c0.c1023Target
Context: system_u:object_r:home_root_t:s0Target
Objects: home [ lnk_file ]

Resolved,
 

Thank you very much, livewire98801,

I had to correct audit violations by the followings:

audit2allow -M spamd -i /var/log/audit/audit.log
semodule -i spamd.pp

I can have a good sleep now, :)

Further investigation
 

Can anyone tell me why I did not have this problem before
moving /home to different partition?

It seems softlink plays a major role here because I compare /home (softlink), /app/home (new home) and /home_hold (original home).
They have exactly the same owner, mod, contect.

Where doe the link link to and what is the context of the target? I still expect the context needs to be user_u

Checked the other system (Fedora 7), found the same context system_u of /home, however, I changed /home and its target /app/home on this system (Fedora 10) to user_u, and it still works also. I think "touch /.autorelabel;reboot" changed lots of context to system_u:object_r:default_t, and I had to compare with (Fedora 7) to change them back.

In such case, I am going to move /var/log and /www out, should I changed /www to user_u also and keep system_u for /var/log?

Thanks,

Problems to move /var/log
 

And,
I had not problem to move /www because I can check audit log and correct them.
However, I had problem to move /var/log because nothing will be logged in audit.

Any idea to corret this problem?

Thanks,

/var/log is var_log_t, whereas /var is var_t

Yes, they are set this way,
I think the only way available to me now is to
have /var/log in a LogVol itself and mount them during boot time. Later, I can move /www, /home here because
errors will be logged and fixed accordingly.

The softlink /var/log -> /app/log did not work, and errors were not logged. I had no way to fix it.

Thanks, billymayday,

I realize this is an old thread but as it is still the first hit I found on Google, I'll post my solution in case it helps someone.

I was having this same issue on Red Hat 6. This machine has a combination of local and Active Directory users using Samba/Winbind for authentication. This involved a local user who ran into this issue that we'll call 'user1'. He made the mistake of attempting a login with his caps lock on effectively logging in as 'USER1'. This failed but when he attempted to login again he got the permission error. We have our Samba/Winbind set to auto-create a directory for new users if it doesn't exist. I suspect that there is some sort of case-insensitive bug or something that tried to touch the existing /home/user1 directory.

To fix I simply reset the regular perms and it worked
1) login as root
2) cd /home
3) chown user1:user1 user1
4) chmod 700 user1

I hope this helps.