permissions ssh

ssh “permissions are too open”


I get the following error from ssh:

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

What permissions should I give to the id_rsa file?


  • 66

    Thanks for asking the quesiton. A better experience would be for the one who wrote this error message to suggest a few valid configurations (such as 600 or 400 as suggested below). Programmers not writing sufficiently complete error messages that are helpful have been torturing all of us for years!

    Apr 11, 2018 at 14:37

  • FWIW, this is related to StrictModes being enabled on the sshd server, from the man page: “StrictModes Specifies whether sshd(8) should check file modes and ownership of the user’s files and home directory before accepting login.” – you could disable this however not suggested.

    – masseyb

    Aug 29, 2019 at 8:34

  • Instead of It is recommended my os shows It is required. Maybe my os is newer (2020) and that`s why.

    – Timo

    May 27, 2021 at 19:58

  • Also applies to other setups, such as even Permissions 640 ... are too open and other OSes such as Unix as well as Linux

    – Cadoiz

    Nov 25, 2021 at 14:45

  • Unfortunately, the question cannot be edited any more. Title cannot contain "ssh "permissions are too open" error" It tells me “Please provide a title that summarizes your question. For assistance, see: How do I ask a good question?” – which I want to suggest and share here and now.

    Nov 29, 2021 at 10:58


The keys need to be read-writable only by you:

chmod 600 ~/.ssh/id_rsa

Alternatively, the keys can be only readable by you (this also blocks your write access):

chmod 400 ~/.ssh/id_rsa

600 appears to be better in most cases, because you don’t need to change file permissions later to edit it. (See the comments for more nuances)

The relevant portion from the manpage (man ssh)

         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.


  • 355

    400 is too low as that makes it non-writable by your own user. 600 is actually recommended as it allows owner read-write not just read.

    – jfreak53

    Jul 9, 2013 at 23:55

  • 11

    I discovered today there are times when 400 is relevant. Suppose you have an authorized_keys file that has the no-pty et al features set. If the file is writeable, the user can actually overwrite the authorized_keys file and gain interactive shell access! Something to keep in mind, though surely not the general case for most folks.

    Nov 16, 2013 at 0:35

  • 22

    AWS actually recommends permission 400 on their website. That’s what I did on OS X and it worked.

    Jan 6, 2016 at 15:26

  • 8

    This definitely works and is more secure. The only downside is you then have to change it to 600 to edit. For id_rsa, and I doubt that matters because you rarely ever will edit those files, but for authorized_keys, it could be annoying. Best to understand the tradeoffs and configure each system appropriately.

    Jan 6, 2016 at 17:11

  • 6

    I suppose it also depends on how often you’re editing them. Many people set it and forget it, thus 400 would be more secure from others and your own actions; modifying to 600 when necessary. If it’s part of your workflow and your ssh-savy, then maybe it would be more of a hindrance to keep changing permissions.

    – vol7ron

    Jun 1, 2016 at 14:27


Using Cygwin in Windows 8.1, there is a command need to be run:

chgrp Users ~/.ssh/id_rsa

Then the solution posted here can be applied, 400 or 600 is OK.

chmod 600 ~/.ssh/id_rsa

Reference here


  • 8

    locale-dependent. I had to run “chgrp Użytkownicy ~/.ssh/id_rsa” since “Users” errored no such group.

    – Marcos

    Sep 26, 2014 at 18:44

  • I had to do this as well. My cygwin directory was in the default location (C:\cygwin64) so it probably inherited the permissions. Strange that this didn’t happen on other laptops I’ve owned.

    Oct 15, 2014 at 1:32

  • 3

    @Marcos I’ve added an answer that works regardless of locale:

    – thehouse

    Feb 21, 2015 at 15:53

  • 4

    Windows 10. Used the second command only. Worked like a charm.

    – StalkAlex

    Dec 8, 2015 at 12:16

  • Note that for installations in alternative languages the ‘Users’ group has alternative identifiers.

    Oct 27, 2016 at 18:00


I’ve got the error in my windows 10 so I set permission as the following and it works.

Permission for id_rsa of windows 10

In details, remove other users/groups until it has only ‘SYSTEM’ and ‘Administrators’. Then add your windows login into it with Read permission only.

Note the id_rsa file is under the c:\users\<username> folder.


  • I have the same problem on Win-10. Based on your explanation, not clear what did you actually allowed and denied – I have “users’ and ‘authenticated users’ and Not ‘specific user” as options + System and Administrators. Besides I could not figure out cygwin – to install or use.(?)

    – Sam-T

    Oct 16, 2019 at 0:13

  • 17

    for Win10 need move your key to user’s home – this worked perfectly. I was trying giving full path to key and messing with the permissions – nothing worked.

    – Sam-T

    Oct 16, 2019 at 0:44

  • @Sam-T if you cannot see your name in list, you can add by press Edit... then press Add... then type your name in the text box "Enter the object names to select" then press Check Names button (and press OK and another OK) then your name should be listed in the Security tab

    Oct 16, 2019 at 19:23

  • 2

    I probably can add the name specifically – per your instructions. But my main question was – what exact permissions to Deny and Allow for all. Meanwhile as mentioned I was able to solve the problem by simply adding the .pem to the myuser directory

    – Sam-T

    Oct 16, 2019 at 20:31

  • Oh thank you. This worked perfectly on windows 10, I was trying to achive this for weeks.

    Jan 22, 2021 at 19:16