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.

It took me hours to solve this SSH problem with one of my class accounts on my school's servers.

I couldn't ssh into one particular class account without entering my password, while passwordless authentication worked with my other class accounts. The .ssh/ directory and all of its contents had the same, correct permissions as the other class accounts.

Turns out the problem was the permissions set on my own home directory. Passwordless authentication did not work when the permissions on my HOME directory were set to 770 (regardless of the permissions set for .ssh/), but it worked with permissions set to 755 or 700.

Anyone know why SSH does this? Is it because the home directory permissions are too permissive? Why does SSH refuse to authenticate with the public/private keys when the home directory is set more permissive than 700?

share|improve this question
Confirmed the answers below; the problem was the group permissions on the home folder were incorrectly set (the error message from auth.log was: ‘Authentication refused: bad ownership or modes for directory /home/<user>’). I see SSH is right to be picky about home dir permissions. –  action_potato Apr 23 '12 at 20:54
Did you know about the tag wikis we have here? If you click on ssh and then learn more, you'll see a checklist for what to do when SSH isn't working, and it mentions the home directory permissions. –  Gilles Apr 23 '12 at 23:34
Ah, sorry I didn't know about that! Thanks for the heads up. –  action_potato Apr 24 '12 at 0:03

2 Answers 2

77x on your home directory means that everybody with correct GID can move your .ssh directory and replace it with another one. Users with the correct GID have write/exec permissions on the home directory and therefore can rename/create files/directories.

SSH is very picky when it comes to permissions, and it should.

share|improve this answer

This is the default behavior for SSH. It protects user keys by enforcing rwx------ on $HOME/.ssh and ensuring only the owner has write permissions to $HOME. If a user other than the respective owner has write permission on the $HOME directory, they could maliciously modify the permissions on $HOME/.ssh, potentially hijacking the user keys, known_hosts, or something similar. In summary, the following permissions on $HOME will be sufficient for SSH to work.

  • rwx------
  • rwxr-x---
  • rwxr-xr-x

SSH will not work correctly and will send warnings to the log facilities if any variation of g+w or o+w exists on the $HOME directory. However, the administrator can override this behavior by defining StrictModes no in the sshd_config (or similar) configuration file, though it should be clear that this is not recommended.

share|improve this answer
This answer only repeats the facts, it doesn't explain anything. –  Gilles Apr 23 '12 at 23:35
@Gilles Edited per your observation –  uther May 1 '12 at 20:56
Thanks for mentioning StrictModes no. In my setup, an ACL is configured on the target user's home directory and all descendants to allow modifications by a semiprivileged user (u:operator:rwx), and SSH didn't like this. –  intelfx Jul 25 at 2:06

Your Answer


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.