7

Just finished a simple local file inclusion challenge and I wanted to make sure if I understood the issues around permissions and SSH keys correctly:

-We set private ssh keys to 600 so only the user who owns them can read them. Say we had 777 instead of 600: That means that any user (so for example, www-data) can read them and thus can obtain the private key.

What I don't understand is how or why when trying to connect over SSH to another host, said host knows that we have such permissions. (Is it the server or the local SSH process running that warns us?).

And what is the minimum accepted to connect? I.e. the less restrictive permissions

1
  • 3
    Changing the permissions when they are wrong (as prompted by the ssh client sanity check) is actually doubtful. Creating a new key would be better. But the check does educate users and tool authors to do better in the long run. And it does not help against local file includes. A HSM/smartcard, isolated agent or Token (-sk keys with fido) are better for that.
    – eckes
    Oct 17 at 4:11
28

It is not about the SSH server knowing about the file permissions of the client. The scenario is instead having multiple users on the same computer or on the same shared network file system. Since the private key should identify a specific user it is necessary that other users on the same shared resource cannot read or manipulate the private key, i.e. the minimum permissions should allow read and write access only for the user itself, i.e. -rw------- which translates to (octal) 0600.

2
  • 16
    No need for write permission after you've created the file.
    – Barmar
    Oct 15 at 19:53
  • 1
    Read-only is chmod 400
    – Nelson
    Oct 18 at 8:20
20

Is it the server or the local SSH process running that warns us?

It's the local SSH process. The remote server does not have access to your local files, it does not read your keys and have no idea what is on your side. Your local SSH process reads your key and uses it to authenticate itself to the remote server, and warns you about the insecure key permissions.

And what is the minimum accepted to connect?

The required (not the accepted) is to the key file to be readable only by the owner. So the answer is chmod 600 on the key. You could chmod 700 on it to mark it executable, but it would not execute anything and it would be accepted by ssh.

8
  • @FedericoPoloni Good point!
    – ThoriumBR
    Oct 15 at 16:34
  • 2
    The local client could work if the file was world readable, but flags an error so the user notices right away. Oct 15 at 16:52
  • 12
    0400 should be enough. 0600 is read-write.
    – ilkkachu
    Oct 15 at 21:19
  • 0400 is the most restrictive permission. OP is asking for the least restrictive permission that still works.
    – ThoriumBR
    Oct 17 at 7:21
  • 1
    @Prem 000 won't work because you will start ssh as your own ID, not root. And it would be silly to make ssh a suid.
    – ThoriumBR
    Oct 17 at 19:35
3

There seems to be alot of confusion in the answers provided so far. Beware!

In SSH public key authentication, there are two keys involved:

  • The private key - which exists on the SSH client - a typical filename is ~/.ssh/id_rsa
  • The public key - which exists on the SSH server - a typical filename is ~/.ssh/authorized_keys

Effectively, the SSH private key serves as a replacement for your user password. Because of this, it, itself can optionally be password protected.

Note that:

  • The public key is derived from the private key (see 'ssh-keygen -y').
  • SSH Host keys also come in private and public flavors. SSH User keys and SSH Host keys are used for different things - Host keys are usually at /etc/ssh/ssh_host_key (private) and /etc/ssh/ssh_host_key.pub (public) - these keys drive what ends up in ~/.ssh/known_hosts
  • Often times folks will copy both the public key and the private key to both client systems and servers. That's fine, but not strictly necessary. (Think of a scenario where you don't have control over (or don't trust) but still wish to authenticate to the system using public key - you wouldn't give an untrusted host your private key.

Because of the above:

  • The ssh client software (ssh/sftp/scp/etc) is concerned about the permissions and ownership of the private key file (~/.ssh/id_rsa, for example). Because it's your "private" key, the permissions are expected to reflect that no other user besides the owner can read or write the file - therefore, the ~/.ssh/id_rsa file must be permission mode 00600 (or better). If it was mode 00640, then your group could possibly read your private key, and that would be enough for the ssh client software to reject it's use. Note also that every individual directory leading to this file is also validated.
  • The ssh server software (sshd) is concerned about the permissions and ownership of the public key file (~/.ssh/authorized_keys). Because it's your public key, the ssh server software is less concerned about keeping it private, but more concerned about ensuring it cannot be tampered with (read: written to). Therefore, sshd will reject use of a public key if it's permissions and ownership allow write access to a user other than the owner. Usually, mode 00644 works fine, thought many confuse the permissions on id_rsa with authorized_keys. Mode 00664 is too permissive for a public key file, since it implies any other users in your group could change your public key and impersonate you by injecting their own public key to or ~/.ssh/authorized_keys (for example). Note also that every individual directory leading to this file is also validated.

Ensure you understand the "leading to this file" part: if /home/username is mode 00775, then the group assigned to it can modify it's contents (e.g., could rename / remove / replace /home/username/.ssh/) and that can also cause things to fail.

On the client, where the private key lives, the most permissive permissions are:

  • / root:root 00755
  • /home root:root 00755
  • /home/username username:group 00755
  • /home/username/.ssh username:group 00755
  • /home/username/.ssh/id_rsa username:group 00600

On the server, where the public key lives, the most permissive permissions are:

  • / root:root 00755
  • /home root:root 00755
  • /home/username username:group 00755
  • /home/username/.ssh username:group 00755
  • /home/username/.ssh/authorized_keys username:group 00644

(You could probably make the files executable and it'd work, but that's kinda silly)

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.