sshd will refuse to accept public key authentication if the user's home directory is group-accessible, even if ~/.ssh is set to 700? If the permissions on ~/.ssh are acceptable, why do the permissions on ~ matter?

2 Answers 2


I guess the reason is that if your home directory is writable by someone else, then a malicious user can create ~/.ssh, add desired keys and then change permissions on it to 700.

Even if you already have a ~/.ssh, it can simply be renamed to something else and a new one created.

However, on modern systems such trick is usually not possible due to chown working only for super-user, this has not always been the case:

In earlier versions of UNIX, all users could run the chown command to change the ownership of a file that they owned to that of any other user on the system. (http://www.diablotin.com/librairie/networking/puis/ch05_07.htm)

Whether chmod behaves one way or another depends on libc compilation options, and for the sake of security OpenSSH server is slightly paranoid.

  • 1
    They wouldn't be able to chown it to you, though, not without root access…and if they have root access, they can get into ~/.ssh anyway. Aug 25, 2012 at 8:42
  • @BlacklightShining updated the answer
    – aland
    Aug 25, 2012 at 14:24
  • Thanks, that makes more sense now. Is there any way, then, to make ssh not do this strict checking? And, since directories you make have your usergroup by default (which only you belong to), isn't 700 as safe as 770? Aug 31, 2012 at 0:11
  • @BlacklightShining You can use StrictModes no in sshd_config, but it will disable all permission checks. You can also change the location of your authorized_keys file with AuthorizedKeysFile option to be outside your $HOME. There is no way. to my knowledge, to disable only one of permission checks unless you modify ssh-server's source code.
    – aland
    Aug 31, 2012 at 16:27

Okay to fix this you could either go the insecure route and set StrictModes no in your /etc/ssh/sshd_config as was already mentioned or you could go the complicated way and store the ssh-keys for all users in a directory accessible to root only. Here a the steps for the latter:

  1. Create a directory to hold the new keys. Here we'll use /usr/share/sshkeys, wich might not be the best place but the best I can think of out of my head.

    sudo mkdir /usr/share/sshkeys
  2. Edit /etc/ssh/sshd_config to include the line

    AuthorizedKeysFile /usr/share/sshkeys/%u
  3. Copy the old authorized key file from your user (here called "exampleuser") to the new directory

    mv /home/exampleuser/.ssh/authorized_keys /usr/share/sshkeys/exampleuser
  4. (Optional but recommended since exampleuser will expect to be able to add keys the usual way) Link the new keyfile to the location of the old and give the user access to the new key file

    sudo chown exampleuser /usr/share/sshkeys/exampleuser
    sudo chmod 600 /usr/share/sshkeys/exampleuser
    ln -s /usr/share/sshkeys/exampleuser /home/exampleuser/.ssh/authorized_keys
  5. Restart the ssh daemon

    sudo service sshd restart
  • Perfect. Now we just need a way to have this be set up automatically with dpkg-reconfigure openssh-server. Jan 26, 2013 at 17:05
  • Wait, what about the other files in ~/.ssh? Won't ssh complain about them being insecure? An attacker wouldn't be able to read them, but they could move ~/.ssh aside and make a new one with whatever known_hosts they like… Jan 26, 2013 at 17:23
  • Nope, the location of the keyfile was changed in /etc/ssh/sshd_config. That means ssh will check the permissions of the new file which are not group readable. All an attacker can do is change a file now rendered irrelevant to ssh. The link is just so the user knows where his new file is.
    – con-f-use
    Jan 27, 2013 at 11:17
  • Also I corrected the mixup of files in step 4. I don't know whether ssh checks the permissions on the other files in ~/.ssh. For me it didn't. If it does for you, relocate the other files in the same manner. The file holding the authorized_keys is however by far the most important to security.
    – con-f-use
    Jan 27, 2013 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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