You are not logged in.

#1 2013-01-29 06:37:40

matthew02
Member
Registered: 2012-08-01
Posts: 28

SSH Key File Permissions

This may not actually be a problem, but I want to make sure that I am not missing anything. I have set up my SSH keys and copied the public key to the server following the wiki. When I get to 4.1 Securing the authorized_keys file, I have trouble. If I have the public key file permissions set to 600 and owner as root:root. I cannot authenticate. The server complains thus.

debug1: Could not open authorized keys '/etc/ssh/authorized_keys/redacted': Permission denied

When I change the permissions to 604 or give ownership of the file to the user in question, authentication works. If the purpose is simply to keep users from adding new public keys, then is having 604 permissions really a problem? Also, since I am administering my own machines without other users, is this even necessary? Thanks.

Offline

#2 2013-01-29 07:20:12

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,089

Re: SSH Key File Permissions

I would keep the default configuration: having a file $HOME/.ssh/authorized_keys in the user account containing the keys of the users allowed to login. I have not read this wiki in full detail but understand what you are trying to achieve. If a user can log in with a password, it would not be more secure to disallow him to put a key in his $HOME/.ssh/authorized_keys since he can log in anyway. Actually, it is more secure to log in with $HOME/.ssh/authorized_keys instead of a password (because passwords are usually shorter and could be more easily guessed); this is the reason some servers disallow password login.

Last edited by olive (2013-01-29 07:29:57)

Offline

#3 2013-01-29 20:58:30

matthew02
Member
Registered: 2012-08-01
Posts: 28

Re: SSH Key File Permissions

Thanks for the response. Password logins are disallowed on my server. I am actually just interested in the best practices for SSH server security. As you stated, preventing the users from modifying their key files may not generally increase security at all. If that is true, then in what scenario would someone do this? Also, why don't the permissions stated in the wiki work? Is the wiki wrong? Thanks.

Offline

#4 2013-01-30 05:23:33

hunterthomson
Member
Registered: 2008-06-22
Posts: 794
Website

Re: SSH Key File Permissions

matthew02 wrote:

Thanks for the response. Password logins are disallowed on my server. I am actually just interested in the best practices for SSH server security. As you stated, preventing the users from modifying their key files may not generally increase security at all. If that is true, then in what scenario would someone do this? Also, why don't the permissions stated in the wiki work? Is the wiki wrong? Thanks.

Hum..., well I guess there could be some security in not allowing users to modify their authorized_keys file. Kind of.... but not really. Basically if your in the position where you the Admin want to control what keys are authorized then you will want to use LDAP..... But like "what if", an attacker "somehow" gets temporary access to the server as a user.... Like an easy example, say the user goes to take a pee, then an attacker hops on the users keyboard and quickly uploads the attacker's pub-key and puts it in the authorized users file..... preventing the user from having the authority to modify the authorized_keys file would prevent that.

Anyway, secure or not here is how you could do it...

username="bob"
groupadd -g 888 $username
gpasswd -a $username $username
chown -R root:$username /home/$username/.ssh
chmod 760 /home/$username/.ssh
#
# It would be critical to set the immutable attribute
# This way the user can not just delete the file
# and create a new one that they have control over
chattr +i /home/$username/.ssh/authorized_keys
#
# If you have and Eliptical Cureve Key use the first
# If you have DSA ... you get the idea....
chown 640 /home/$username/.ssh/id_ecdsa
chown 640 /home/$username/.ssh/id_dsa

Last edited by hunterthomson (2013-01-30 05:27:52)


OpenBSD-current Thinkpad X230, i7-3520M, 16GB CL9 Kingston, Samsung 830 256GB
Contributor: linux-grsec

Offline

#5 2013-02-01 02:33:42

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,661

Re: SSH Key File Permissions

But couldn't the attacker equally easily copy the private key from the user's directory, in that case? And then the attacker can use that on another machine. Moreover, such an attack is less easily detected than replacing the public key on the server. Or am I missing something? (Highly likely.)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#6 2013-02-01 07:23:07

olive
Member
From: Belgium
Registered: 2008-06-22
Posts: 1,089

Re: SSH Key File Permissions

cfr wrote:

But couldn't the attacker equally easily copy the private key from the user's directory, in that case? And then the attacker can use that on another machine. Moreover, such an attack is less easily detected than replacing the public key on the server. Or am I missing something? (Highly likely.)

I've tried to think of the situation it would make sense, but I only come to the conclusion that it would probably be more secure to let the user add and remove its own keys. Suppose a user suspect that his private key has been stolen. He could then quickly replace its authorized_keys file and the system is once again secure. Otherwise he would have to phone/e-mail the sysadmin and ask him a new key; which inevitably take some time. Now suppose moreover that the user user has done a fault; I just think of secret agent who have left his laptop unsupervised in a public environment while he was going to pee. He would prefer not to conceal his fault and hope nobody has stolen the key.

Offline

#7 2013-02-01 22:51:04

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,661

Re: SSH Key File Permissions

@olive,

Glad it is not just me anyway smile.


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#8 2013-02-11 04:54:56

matthew02
Member
Registered: 2012-08-01
Posts: 28

Re: SSH Key File Permissions

hunterthomson wrote:

Like an easy example, say the user goes to take a pee, then an attacker hops on the users keyboard and quickly uploads the attacker's pub-key and puts it in the authorized users file.....

Funny example, but it could happen. You're sitting in the computer lab and Kevin Mitnick is sitting across from you...

A more believable example for a home network could be a zero day exploit that allows access to a user account on the server whereby the attacker adds an authorized ssh key and gains permanent access. It does seem reasonable to limit access to the authorized_keys file in this case. The best I can tell, the instructions in the wiki used to work until someone edited them. At any rate, it seems like the desired result could be accomplished by simply leaving the authorized_keys file in its original location with original owner and then changing the permissions to 400 and setting the immutable bit. Any reason why that wouldn't work?

Offline

#9 2013-02-12 02:16:58

kpiche
Forum Fellow
From: Ottawa, ON, Canada
Registered: 2004-03-30
Posts: 246
Website

Re: SSH Key File Permissions

I'm not sure if it's clear but the private key should not go on the server - it's "private".  The authorized_keys file should be a *.pub file(s).  I don't see the benefit of preventing the user from changing the public key.  If the private key is stolen and the passphrase known it doesn't matter where on the server the public key is.

Offline

#10 2013-02-12 04:10:13

matthew02
Member
Registered: 2012-08-01
Posts: 28

Re: SSH Key File Permissions

This is not about the private key, nor is it about someone stealing your public key. The point is to keep an attacker from appending their public key to your authorized_keys file and then having unfettered access to your account with you being unaware.

Offline

#11 2013-02-12 19:25:49

kpiche
Forum Fellow
From: Ottawa, ON, Canada
Registered: 2004-03-30
Posts: 246
Website

Re: SSH Key File Permissions

I didn't say anything about stealing a public key either.  It is about the private key though because you say you're worried about the attacker appending to the authorized_keys file but if they can do that they've already logged into the server with your private key (since you don't allow passwords).  The passphrase is the only thing preventing the attacker from using a stolen private key.

Offline

#12 2013-02-13 02:07:36

matthew02
Member
Registered: 2012-08-01
Posts: 28

Re: SSH Key File Permissions

kpiche wrote:

I didn't say anything about stealing a public key either.

I was only trying to clarify a point, not meaning to put words in your mouth.

kpiche wrote:

It is about the private key though because you say you're worried about the attacker appending to the authorized_keys file but if they can do that they've already logged into the server with your private key (since you don't allow passwords).  The passphrase is the only thing preventing the attacker from using a stolen private key.

I think this is more about someone gaining access to your system through some social engineering or software exploit rather logging in with your private key. In the case of a software exploit, even if you were to patch the hole, an attacker could have added their public key to your system and would have access after the patch. The case is similar with social engineering. Either way, the attacker could then be accessing your system nearly transparently. If you aren't checking your logs, it might be a while before you discover it.

I also want to point out that this is not my idea. I found this tip in the Arch wiki and it has been there for nearly a year. It may not be worthwhile for everyone, but there is minimal effort required to change the permissions and set the immutable bit. Figuring that there are probably many users with only one public key in their authorized_keys file, it could be worth their time if only to prevent that one rare circumstance from causing an extra headache. Either way, the wiki needs to be modified. If the consensus is that this is pointless, then we should remove that section of the wiki. If anyone finds this valuable, then we need to update the broken instructions. I'm happy to do either.

Offline

Board footer

Powered by FluxBB