Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have some users which have different $HOME directories than /home/...

The user homes are under /pkg/homeand /pkg owner is a different user but all users have group access to /pkg. But it seems SSHD will restrict access to authorized_keys (e.g. /pkg/home/usera/.sshd/authorized_keys) because the user is not owner of the full path.

Is there any option for sshd_config to change this restriction?

share|improve this question
3  
I don't think that this is the reason. If $HOME is /home/usera the user also will not be owner of the full path (the meaning is usera will not be owner of /home). can you show the ls -ld /pkg /pkg/home /pkg/home/usera /pkg/home/usera/.ssh /pkg/home/usera/authorized_keys for a problem user? –  miracle173 Sep 13 '12 at 20:39
    
Thx, you are right. File permissions were correct, both 700. Problem was caused by SELinux. I found out that I had to run the command 'restorecon -R -v ~/.ssh' bugzilla.redhat.com/show_bug.cgi?id=476362 –  marquies Sep 14 '12 at 7:22

3 Answers 3

It doesn't matter who owns /pkg/. If it would be owned by usera then you would have problems with userb etc. So it must be something else that prevents SSHD from using authorized_keys file. You have to check if this file is writable only by the owner and if it is owned by proper user. The same applies all parent directories.

share|improve this answer
    
Thx, you are right. File permissions were correct, both 700. Problem was caused by SELinux. I found out that I had to run the command 'restorecon -R -v ~/.ssh' bugzilla.redhat.com/show_bug.cgi?id=476362 –  marquies Sep 14 '12 at 7:22
    
I'm glad you where able to find that out. It's a good idea to mention in question that you are using SELinux if you have any problems with permissions, access etc. –  Krzysztof Adamski Sep 14 '12 at 7:27

It's all or nothing: if you turn the StrictModes option off, sshd will never check any file modes. There's no way to say that certain odd cases are ok, such as a group-writable directory (which is ok if the user is alone in the group).

OpenSSH checks the permissions and ownership of ~/.ssh/authorized_keys and its containing directories recursing upwards. However, it stops the comparison when it reaches the home directory. For example, in the classical arrangement where the authorization file is /home/joe/.ssh/authorized_keys and /home/joe is the user's home directory, only /home/joe/.ssh/authorized_keys, /home/joe/.ssh and /home/joe are checked.

So while your scenario is highly dubious (/pkg should be owned by root, with additional group permissions if required), it should not impact ssh.

If any symbolic links are involved, note that ssh expands all symlinks before starting its checks.

The system logs might have relevant information. Check if your failed login attempts cause any log message.

Check that your version of ssh performs the same checks as mine (I looked at the source of OpenSSH 5.5p1) by running a debug mode daemon on a custom port (sshd -d -p 2222). Use strace -f -efile sshd -d -p 2222 if necessary to check which files' permission the server checks. If these permission checks aren't the issue, adding more -d flags might throw some light.

If you have AppArmor, there's also the possibility that it is restricting the ssh server to reading files in users' .ssh directories. If you have AppArmor and home directories in a nonstandard location, you'll need to update AppArmor policies (not just for SSH). See Evince fails to start because it cannot read .Xauthority.

share|improve this answer

I had the same problem, using '/data' as base dir for the user directories. For me, it was not enough to run 'restorecon -R -v ~/.ssh'. First, I had to run

# semanage fcontext -a -e /home /data

as root, and then (also as root as the /data directory contained a root-owned directory)

# restorecon -R -v /data
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.