Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So over the years I have had to generate, and use a lot of ssh keys. Some of the things that always have to get done are ~/.ssh needs to be 0700 and ~/.ssh/authorized_keys needs to be 0600, and then private keys used to login to a server always need to be 0600. I know ssh enforces these permissions but I wanted to know the reason why its not safe to have the following (Yes I am calling the white hats, black hats and anything in between to get this answer).

  • ~/.ssh/ = 0755
  • ~/.ssh/authorized_keys = 0644
  • ~/.ssh/id_rsa = 644 (or any private key)
share|improve this question
1  
Um, making your keys world readable means anyone can get your private key, meaning they can log into anything you can . . . – ernie Aug 1 '13 at 21:56

For security reasons....to prevent unauthorized users from obtaining any information that might help break your account.

Remember your security principles, only provide the absolute minimum information (if any) necessary to an outside party to perform a task. The designed set of permissions do that. And ssh is designed to be highly trusted security software.

share|improve this answer

Linux file permissions can be expressed as a three-digit number. Each of the digits represent: Owner, Group, Others.

Digit |  Permissions
------------------------------
0     |  None
1     |  Execute
2     |  Write
3     |  Write and Execute
4     |  Read
5     |  Read and Execute
6     |  Read and Write
7     |  Read, Write and Execute

With 755, you'd give reading and execution permissions to everyone. With 644, you'd be giving reading permissions to everyone.

SSH clients and servers will remind you to use strong permissions to ensure that you don't accidentally share your private key with every user on a server.

share|improve this answer

Traditionally, Unix & Linux servers are designed to be multi-user systems. Due to the implications of using Public / Private Key Cryptography, it becomes important to keep the Private Key secret. The octal file permissions meanings are described by @gregory in his answer, and are more fully described by the Unix Modes Wikipedia Page. The rest of my answer will focus on what it seems you're interested in, which are the potential implications of having lax permissions on your ~/.ssh directory and underlying files.

The reasoning for the permissions sshd enforces when StrictModes is on are:

  • ~/.ssh/ = 0700:
    • The entire ~/.ssh/ directory contains files that need to be read by the user running ssh, and written to in the case of ~/.ssh/config.
    • It also contains files that a malicious user could abuse by being able to read or write to. The lax permissions you mention 0755 for this directory, along with the others (~/.ssh/id_rsa = 0644, ~/.ssh/authorized_keys = 0644) would potentially allow a lot of abuses to occur. For example:
      • An attacker might steal ~/.ssh/id_rsa, or other Private Keys in this directory, allowing them to login to any host that the target user is authorized to SSH into. This is why ~/.ssh/id_rsa = 0644 is bad, and it is the most obvious low-hanging fruit an attacker would look for first.
      • An attacker might add their Public Key to ~/.ssh/authorized_keys, which would grant that user access to SSH into the host and masquerade as that user. If the target user is in /etc/sudoers and has passwordless sudo enabled, then this becomes a privilege escalation attack.
        The permissions you mention ~/.ssh/authorized_keys = 0644 wouldn't technically allow this, but it's why sshd's StrictModes on setting enforces strict permissions on this file. Allowing other users to write to this file is bad, reading it isn't as bad, because technically the Public Key does not need to remain secret.
      • An attacker might alter ~/.ssh/known_hosts to override a remote host's public key with one they own, and then perform a DNS cache poisoning attack to redirect the host name to an IP they own. This is basically a man in the middle attack, redirecting the user to their malicious host when the user logs into that host.
      • An attacker might alter settings in ~/.ssh/config to turn off StrictHostKeyChecking to facilitate the above MitM attack.
      • An attacker might do both of the MitM attacks above, then set ForwardAgent yes, and hijack the target user's SSH socket file. When the target user logs into the attacker's MitM host, the attacker would modify file permissions on the SSH agent socket file and then use the remote user's SSH agent (containing their Private Keys) to login to other hosts that the target user is authorized to SSH into.
    • If the version of SSH is old, an attacker might read the old-style plaintext ~/.ssh/known_hosts, in order to gain information about which hosts the target user is able to access.
    • Therefore, the permission bits 0700 ensure the following:
    • 7: Read, write, and execute bits set for the user allow:
      • User may create, rename, or delete files within the directory, and modify the directory's attributes.
        This way the user can create & write to their SSH config file, manage their ~/.ssh/authorized_keys file, etc...
      • The read bit allows the user to list the files within the directory.
        Obviously the user owning the directory needs this to manage the files within.
      • The execute bit allows the user to enter the directory, and access files and directories inside.
        Again, this is obvious and necessary for the user to manage their own ~/.ssh/ directory.
    • 0: No directory permissions for users in the same group and other users ensure that none of the above mentioned hijinks are allowed, at least on the directory level.
  • ~/.ssh/authorized_keys = 0600:
    • Already mentioned above, it's important that this file is owned by the true owner, and that no other user may write to this file.
    • An attacker could modify this file to change options (yes, there is more to this file than just a list of public keys) used for this key when the user connects to the target system.
    • An attacker could modify this file to change the command option to run a command as the user when they login. This could be considered local privilege escalation or local command execution to masquerade as that user.
  • ~/.ssh/id_rsa = 0600 (or any private key)
    • Also mentioned above, it's important that any private key files are owned by the true owner, and that no other user may read or write to them.
    • An attacker could cause a DoS & prevent a target user from being able to login to servers if they can overwrite the private key files
    • As mentioned above, an attacker could read the Private Key files to use as an authentication method to other hosts that the target user has access to.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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