ssh and home directory permissions

Question

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?

Solution 1

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.

Solution 2

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
   

Comments

[Blacklight Shining]

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.

[aland]

@BlacklightShining updated the answer

[Blacklight Shining]

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?

[aland]

@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.

[Blacklight Shining]

Perfect. Now we just need a way to have this be set up automatically with dpkg-reconfigure openssh-server.

[Blacklight Shining]

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…

[con-f-use]

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]

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.