610

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
  • 53,069
  • 19
  • 162
  • 212
  • 15
    ```#!/bin/bash find .ssh/ -type f -exec chmod 600 {} \;; find .ssh/ -type d -exec chmod 700 {} \;; find .ssh/ -type f -name "*.pub" -exec chmod 644 {} \;``` – Akhil Apr 04 '20 at 05:33
  • Thank you @AkhilJalagam, your code just saved me some thinking. I love stuff like that. I know how to do it but why should I if it's already here :D – ThaJay May 20 '21 at 09:05
  • 1
    Simpler version: `cd ~ && chmod 600 ~/.ssh/* && chmod 700 ~/.ssh && chmod 644 ~/.ssh/*.pub` – Joshua M Jun 05 '23 at 03:47

8 Answers8

997

Typically you want the permissions to be:

  • .ssh directory: 700 (drwx------)
  • public key (.pub file): 644 (-rw-r--r--)
  • private key (id_rsa): 600 (-rw-------)
  • lastly your home directory should not be writeable by the group or others (at most 755 (drwxr-xr-x)).

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, and if you did then as he says you will have to enter your password every time unless you use an ssh agent.

Fabs
  • 3
  • 2
  • 26
    I found elsewhere that if using the authorized_keys file, that it should be chmod'd to 640, ie -rw-r----- . – AnneTheAgile Sep 11 '14 at 21:19
  • 11
    Where I can find this info in man pages? – Sonique Nov 17 '14 at 15:56
  • 211
    I have come back to this post about 30 times now. I cant believe I cant remember it. – JREAM Apr 02 '15 at 21:35
  • 2
    You can also safely leave the `.ssh` directory permissions at `755 (drwxr-xr-x)`, as well as the `id_*.pub` and `authorized_keys` permissions at `644 (-rw-r--r--)`. Otherwise other users cannot lookup your public keys, but being able to do so is often convenient if they need to know your public keys to grant you access to some service. – Markus Kuhn Sep 30 '15 at 11:55
  • 12
    The only important things are that nothing in .ssh is writeable to anyone else and none of the secret keys are readable to anyone else. – Markus Kuhn Sep 30 '15 at 11:56
  • 1
    @MarkusKuhn OpenSSH specifies `600` for `authorized_keys` for some reason ([link](http://www.openssh.com/faq.html#3.14)). – augurar Feb 18 '16 at 01:52
  • 1
    @augurar My guess: a world-readable `authorized_keys` file would expose the (public) keys that an attacker could use to gain full access to your account. They'd still need to find one of the private keys, of course. – David Harkness Jun 14 '16 at 20:08
  • 1
    To let others verify your signatures and encrypt files for you, make the public key files (`*.pub`) world-readable and the `.ssh` folder world-readable and -executable. Without the latter, other users won't be able to view the public key files. – David Harkness Jun 14 '16 at 21:02
  • 3
    Why 700? Why would you need anything under `~/.ssh` to be executable? – Cerin Oct 26 '16 at 16:39
  • 1
    Why, after generated, would private key be writeable (600)? Generate the keys, then lock down the folder, no? – xtian Nov 20 '16 at 17:49
  • 4
    The correct permissions for `~/.ssh/config` are `600`. – Florian Brucker Dec 02 '16 at 08:32
  • 6
    @Cerin execute permission on a directory grants the ability to list immediate child files/dirs of that directory, files inside the folder don't "inherit" the execute bit of their parent folder. – Thomas Jan 29 '17 at 08:42
  • 2
    At least some versions of OpenSSH require home directory permissions such that only the user can write the home directory. Otherwise, `~/.ssh` could be replaced by a link, and an arbitrary `authorized_keys` file substituted. – Adam Glauser Aug 03 '17 at 13:12
  • 2
    I get `Permissions 0644 for '/home/user/.ssh/id_rsa.pub' are too open.` on Debian Buster. – Akito Nov 20 '19 at 20:41
  • This answer cannot be correct as the directory is more restrictive than the public key. – Lloyd Dewolf Jan 17 '20 at 16:09
  • 1
    As @Akito mentioned it makes no sense to give id_rsa.pub 0644 if the parent dir has 0700 nobody else than the owner can access the file. – Weltraumschaf Apr 17 '20 at 10:56
  • `664` will raise a *WARNING: UNPROTECTED PRIVATE KEY FILE!* with a `Permissions 0644 for 'varys-new.pem' are too open.` Use `600` instead. – juliangonzalez Apr 22 '20 at 20:34
  • JREAM, this is because you don't try to write this numbers yourself) You are afraid to make a mistake. But when you will try to call to mind some numbers without prompts, quite possibly you will make a mistake, **but an the next you will remember information strongly**. You SHOULD make a mistake. This is a way to remember. This is how a human brain works) – James Bond Aug 23 '20 at 08:18
  • Why do I need write permissions on the private key ? Isn't meant to be static ? – thanos.a Oct 20 '22 at 18:17
  • 1
    @thanos.a There are commands that let you update your keys (upgrade security, change comment). I'm guessing they write to the private key. I doesn't make much sense to remove write permission for yourself, since any program run under your privilege can put the permission back. I dunno if securing this file under root ownership is wise, or if having to sudo every ssh connection is worse. – foxesque Oct 31 '22 at 11:42
  • Is there any reason why you shouldn't use 400 for the private keys? One would only want to read and not write or execute - meaning 400 makes sense, right? If the user ever wanted to manually change the file then as the owner of the file this wouldn't be a problem either... – ojunk Jun 16 '23 at 16:13
143

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
  • 6,141
  • 3
  • 11
  • 16
Alex W
  • 1,896
  • 2
  • 13
  • 14
  • Regarding your first paragraph, I am able to ssh with public/private keys with a user on my local linux box (e.g. `abc`), different from the user on the remote server (e.g. `def@123.456.789`). I just had to make sure the local user owned the local .ssh files (e.g. `abc:abc`, not `root:abc`)` – MW Millar Dec 22 '15 at 09:41
  • 1
    Thanks for putting all the steps and commands for newbies, Alex. Yours is one of the most helpful answers here. – Nav Mar 04 '16 at 06:06
  • 7
    +1. "Authorized_keys file needs 644 permissions" <= that was crucial! – Le Quoc Viet Jun 04 '17 at 17:46
  • If you're giving .ssh directory **700** mode, then there is **no point** in giving r-- to group and others, because **only you** can "go through" .ssh then (assuming no hard links exists for these files). The same for accepted answer. Default 755 is enough. – user3125367 Aug 21 '17 at 09:39
  • 1
    400 for the pem files are sufficient in my experience. – A T Nov 14 '18 at 12:24
  • Thank you! Saved my life... Stupid me, copied authorized_keys file from user to root. Your post helped me figure out that I need chown root:root authorized_keys. That was the solution for me – Dmitry Gusarov Aug 09 '21 at 13:48
64

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
  • 2
Ashutosh Jindal
  • 1,011
  • 8
  • 13
  • 5
    Let's not forget `known_hosts` > _"~/.ssh/known_hosts Contains a list of host keys for all hosts the user has logged into that are not already in the systemwide list of known host keys. [...] This file should be writable only by root/the owner and can, but need not be, world-readable."_ (https://linux.die.net/man/8/sshd) – xtian Mar 10 '21 at 20:55
  • 1
    What about 440 for the private key(id_rsa)? There is a group of 'n' users - which is same person but different accounts so x4x should be fine? Also, the private key doesn't have to be modified so why setting 6xx? – Alan Apr 01 '22 at 19:52
39

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

chmod g-w,o-w ~

Felipe Alvarez
  • 2,054
  • 3
  • 27
  • 37
7

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
  • 410
  • 2
  • 7
  • Thanks for the additional info about the ssh agent. Looks like there is one built into Leopard so I think I'll do that. Having a bit of trouble with it but I'll ask another question. –  Nov 26 '10 at 22:18
  • 9
    Do not underestimate permissions. They definitely still come into play. – Alex W May 15 '15 at 19:49
  • @AlexW They do come into play with other aspects of ssh, but not the one asked about in the question. – cdhowie May 24 '15 at 23:43
  • 3
    If you have no password on private keys (whink of automated remote called scripts), it won't help you. Permissions are necessary here. – nerdoc Jan 07 '16 at 23:13
  • "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?" – Craig Hicks Oct 08 '18 at 03:11
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.

mikentalk
  • 51
  • 1
  • 1
0

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

Artfaith
  • 303
  • 4
  • 13
-2

Don't do any of this by hand and just use webmin web interface with this plugin and do this all in a few clicks of a GUI!

enter image description here

Jonathan
  • 1,678
  • 10
  • 28
  • 47
  • This links to an outside page and has no explanation other than an image with no screen reader text. – Sean Duggan Mar 09 '23 at 13:47
  • `sudo apt install webmin` and then launch the gui via a browser, to install & use webmin and plugins is outside the scope of this answer but its easy – Jonathan Mar 25 '23 at 23:16