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?

  • 2
    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. Apr 23, 2012 at 20:54
  • 7
    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. Apr 23, 2012 at 23:34
  • Ah, sorry I didn't know about that! Thanks for the heads up. Apr 24, 2012 at 0:03

2 Answers 2


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.

  • 2
    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, 2015 at 2:06
  • Is there documentation on this behavior? Clear explanation, by the way.
    – flow2k
    Jul 13, 2021 at 7:30
  • Found it on the man pages of sshd(8), under "authorized_keys" section, e.g. linux.die.net/man/8/sshd.
    – flow2k
    Jul 13, 2021 at 7:42

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .