678

I changed my permissions in my .ssh folder and now when I use a piece of software that uses my private key, I have to type my password each time. What should my permissions be on my id_rsa file to not have to type a password each time I use an app that uses it?

Currently my permissions are set to:

-rw-------@ 1 Jody  staff   114 Nov  4 23:29 config
-rw-------  1 Jody  staff  1743 Oct 21  2009 id_rsa
-rw-------@ 1 Jody  staff   397 Oct 21  2009 id_rsa.pub 
-rw-------@ 1 Jody  staff  3855 Sep 13 22:35 known_hosts
Giacomo1968
  • 58,727

7 Answers7

1123

Typically you want the permissions to be:

Item Sample Numeric Bitwise
SSH folder ~/.ssh 700 drwx------
Public key ~/.ssh/id_rsa.pub 644 -rw-r--r--
Private key ~/.ssh/id_rsa 600 -rw-------
Config ~/.ssh/config 600 -rw-------
Home folder ~ 755 at most drwxr-xr-x at most

I am assuming that you mean that you have to enter your system/user password each time, and that previously you did not have to. cdhowie's response is assuming you set a password/passphrase when generating your keys. If you did then as he says you will have to enter your password every time unless you use an ssh agent.

Dmytro Ovdiienko
  • 235
159

I was struggling with this forever and finally figured out what is needed. Replace $USER everywhere with the SSH username you want to log into on the server. If you're trying to login as root you would need to use /root/.ssh etc., instead of /home/root/.ssh which is how it is for non-root users.

  • Home directory on the server should not be writable by others: chmod go-w /home/$USER
  • SSH folder on the server needs 700 permissions: chmod 700 /home/$USER/.ssh
  • Authorized_keys file needs 644 permissions: chmod 644 /home/$USER/.ssh/authorized_keys
  • Make sure that user owns the files/folders and not root: chown user:user authorized_keys and chown user:user /home/$USER/.ssh
  • Put the generated public key (from ssh-keygen) in the user's authorized_keys file on the server
  • Make sure that user's home directory is set to what you expect it to be and that it contains the correct .ssh folder that you've been modifying. If not, use usermod -d /home/$USER $USER to fix the issue
  • Finally, restart ssh: service ssh restart
  • Then make sure client has the public key and private key files in the local user's .ssh folder and login: ssh user@host.com
Sam Denty
  • 7,426
Alex W
  • 2,086
88

Am posting this as a separate answer since I wanted to see man page recommendations translated into permissions.

Summary based on the man page quotes (linked at the end):

Directory or File Man Page Recommended
Permissions		 Mandatory
Permissions
~/.ssh/ There is no general requirement to keep the entire contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others. 700
~/.ssh/authorized_keys This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others 600
~/.ssh/config Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not writable by others. 600
~/.ssh/identity
~/.ssh/id_dsa
~/.ssh/id_rsa		 These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute) 600
~/.ssh/identity.pub
~/.ssh/id_dsa.pub
~/.ssh/id_rsa.pub		 Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone. 644

All the man page quotes are from http://linuxcommand.org/lc3_man_pages/ssh1.html

cavcrosby
  • 3
Ashutosh Jindal
  • 1,261
40

Also ensure that your home directory is not writeable by other users.

chmod g-w,o-w ~
Giacomo1968
  • 58,727
Felipe Alvarez
  • 2,154
5

Permissions shouldn't have anything to do with this. Your private key is encrypted with the password, so you need to enter it for the private key to be decrypted and usable.

You might consider running an ssh agent, which can cache decrypted keys and will supply them to applications that need them.

cdhowie
  • 396
5

Felipe is correct -- the directory containing your .ssh directory must not be writeable by group or other. Thus chmod go-w ~ is the next logical thing to try if you are still prompted for a password when ssh'ing after running ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys, assuming you don't assign a passphrase in the ssh-keygen command, and your .ssh directory is in your home directory.

Giacomo1968
  • 58,727
mikentalk
  • 51
3

It is worth to mention that the current OpenSSH manual (as of OpenSSH 9.0/9.0p1 (2022-04-08)) generally assumes that the owner of authorized_keys file is the user who authenticates, hence 600 or rw- --- --- in the table ("...read/write for the user, and not accessible by others.").

The main reason is that the SSH daemon/server by OpenSSH generally operates in this order I believe (assuming that the ssh service is running under UID 0):

  1. Checks whether the user who tries to authenticate exists in the environment;

    2.1. In case there's no such, invalidates the request (e.g. May 01 01:12:34 host sshd[123456]: Invalid user user3 from x.x.x.x port 12345);

  2. Creates a separate sshd process with the UID and GID of the authenticating user;

  3. In case of pubkey, the new process tries to read the "authorized_keys" in the configured paths.

    3.1. In case the new process cannot read "authorized_keys" file, exists, and that invalidates the request.

  4. Verifies keypair...

# pstree -pugT:

systemd(1,1)-+...
             `-sshd(40976,40976)-+-sshd(194915,194915)---sshd(194939,194915,user1)-+-sshd(938266,938266)
                                 |                                                   `-tmux: client(194943,194943)
                                 `-sshd(2129889,2129889)---sshd(2130234,2129889,user2)---sshd(2130615,2130615)

A source investigation is required to confirm the above, though to summarize, an OpenSSH server currently reads "authorized_keys" file as the authenticating user's UID and primary GID.

If the mode of "authorized_keys" is 600 and the file's owner is not the UID of the authenticating user, the authentication should fail. This may be a case when "authorized_keys" file were created by root for example.

This release deprecates the sshd_config UsePrivilegeSeparation option, thereby making privilege separation mandatory. Privilege separation has been on by default for almost 15 years and sandboxing has been on by default for almost the last five.

Source: https://www.openssh.com/releasenotes.html

Related: https://serverfault.com/a/861842/345785 (...OpenSSH in version 7.5 deprecated the UsePrivilegeSeparation option...)

Serious Angel
  • 455