# Windows SSH: Permissions for 'private-key' are too open

I've OpenSSH 7.6 installed in Windows 7 for testing purposes. SSH client & server work just fine till I tried to access one of my AWS EC2 box from this windows.

It seems like I need to change the permission on the private key file. This can be easily done on unix/linux with chmod command.

private-key.ppm is copied directly from AWS and I guess the permission too.

C:\>ssh -V
OpenSSH_7.6p1, LibreSSL 2.5.3

C:\>ver

Microsoft Windows [Version 6.1.7601]

C:\>

C:\>ssh ubuntu@192.168.0.1 -i private-key.ppk
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'private-key.ppk' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
ubuntu@192.168.0.1: Permission denied (publickey).

C:\>
C:\>
C:\>ssh ubuntu@192.168.0.1 -i private-key.ppm
Warning: Identity file private-key.ppm not accessible: No such file or directory.
ubuntu@192.168.0.1: Permission denied (publickey).

C:\>

• Have you tried modifying the ACL? – Ignacio Vazquez-Abrams Feb 18 '18 at 5:12
• Is your private key actually in C:\ root path? I can see why it is complaining as usually things in C:\ are accessible by everyone. Have you tried moving it to a folder that only you as the user have access (eg. C:\Users\username\desktop) and see if that message still comes up? – Darius Feb 18 '18 at 5:19
• @Darius, yes it is. When you copy a file from unix/linux to windows, the permission is copied as well. I need to change this but not sure how to do it on windows. This can be easily done on unix/linux with chmod command. – Sabrina Feb 18 '18 at 5:27
• @IgnacioVazquez-Abrams, ACL? What kind of ACL? – Sabrina Feb 18 '18 at 5:28
• @Sabrina Either you use icacls command to change permission, or simply right click on the Private Key, and choose Properties, and check under "Security" tab. And make sure that it is only accessible by you / whoever supposed to be able to access the private key. If "Users" have read access - means anyone that have access to the system can read that private key. – Darius Feb 18 '18 at 5:30

You locate the file in Windows Explorer, right-click on it then select "Properties". Navigate to the "Security" tab and click "Advanced".

Change the owner to you, disable inheritance and delete all permissions. Then grant yourself "Full control" and save the permissions. Now SSH won't complain about file permission too open anymore.

It should end up looking like this:

• I'd just like to add 1) This method works on my Windows 10 (10.0.17134.191) box w/Cygwin ver CYGWIN_NT-10.0-WOW 2.3.1(0.291/5/3) 2015-11-14 12:42 and ssh ver OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4, and 2) Thanks! @iBug! – atreyu Jul 28 '18 at 15:10
• Actually, I did that and it still complains that 0777 permissions are too open. – Aaron Bramson Sep 4 '18 at 8:25
• Why is this so difficult on windows, can someone just add a --ignore-stupid-rule command option? – Liam Mitchell Dec 20 '18 at 20:57
• Thanks, worked like a charm. – giovannipds Sep 2 '19 at 17:46
• I still get: Permissions 0770 are too open – Buntel May 13 '20 at 21:17

Keys must only be accessible to the user they're intended for and no other account, service, or group.

• GUI:
• [File] Properties - Security - Advanced
1. Set Owner to the key's user
2. Remove all users, groups, and services, except for the key's user, under Permission Entries
3. Set key's user to Full Control

• CLI:

 :: # Set Variable ::
Set Key="C:\Path\to\keyfile"

:: # Remove Inheritance ::
Cmd /c Icacls %Key% /c /t /Inheritance:d

:: # Set Ownership to Owner ::
Cmd /c Icacls %Key% /c /t /Grant %UserName%:F

:: # Remove All Users, except for Owner ::
Cmd /c Icacls %Key% /c /t /Remove Administrator "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users

:: # Verify ::
Cmd /c Icacls %Key%

• What if the owner is actually a group? In my case, I have a file owned by network service so Cygwin thinks the permission is 0770 instead of 0700. – hyspace Nov 12 '18 at 21:29
• A file must be owned by a user and a group, not just a group. Group permissions are the 3rd octal [user is the 2nd] in a four octal specification and SSH keys cannot be group or others accessible – JW0914 Nov 13 '18 at 3:16
• That is the case of Unix. In Windows, network service can own a file and it is a group – hyspace Nov 13 '18 at 18:40
• Cygwin allows POSIX API functionality on Windows, but it still operates under the rules of the native UNIX based programs (hence 3 & 4 octal permissions in a UGO setup). While you can open an issue on Microsoft's Win32-OpenSSH's GitHub, since SSH keys must be group and others inaccessible, having ownership in the way you describe is likely not supported. It's better to conform to a program's norm than attempt to configure it in a [likely] non-supported way. – JW0914 Nov 16 '18 at 13:52
• this should be correct answer. Thanks for CLI options. GUI always sucks in windows case. – shyammakwana.me Apr 30 '19 at 20:51

In addition to the answer provided by ibug. Since i was using the ubuntu system inside windows to to run the ssh command. It still was not working. So i did

sudo ssh ...


and then it worked

• sudo should not be utilized to open an SSH session as it's a security risk. The only time (at least that I'm aware of) root's account should be utilized to open an SSH session is on single-user systems (i.e. normally found on router OS's [OpenWrt, DD-WRT, etc.] and other embedded systems). SSH keys must be accessible only to the user they're for and no other account, service, or group. – JW0914 May 27 '19 at 18:03
• @JW0914 LOL I have a single-user Debian server and the sole (login) user is root. I don't think an extra non-root user is beneficial because it's my personal server and I login only when performing maintenance work. – iBug Oct 28 '19 at 5:12
• @iBug Please re-read my comment, as it appears you entirely missed the second sentence... – JW0914 Oct 28 '19 at 12:02
• Best answer. When using ubuntu shell on Windows, the advise about safety of the root access is totally irrelevant – Dmitry Torba Apr 5 '20 at 1:19
• This worked for me. I did the above solutions and was still getting the 0077 warning but this fixed it. – Timothee Legros Sep 7 '20 at 22:07

I had a similar issue but I was at work and don't have the ability to change file permissions on my work computer. What you need to do is install WSL then copy the your key to the hidden ssh directory in WSL:

cp <path to your key> ~/.ssh/<name of your key>


Now you should be able to modify the permissions normally.

sudo chmod 600 ~/.ssh/<your key's name>


Then ssh using WSL:

ssh -i ~/.ssh/<name of your key> <username>@<ip address>

• Best answer here. – Raiden Core Aug 31 '20 at 14:42
• +1 - this appears to be the working solution for Windows Terminal / WSL1+2 users. I also did a chown for good measure and used sudo ssh and I was able to connect. – alex Sep 17 '20 at 14:37

You just need to do two things:

1. Disable inheritance

2. Convert inherited permissions to explicit permissions

3. Remove Users group

4. You will end up with no Users can access private files, this should be enough to add id_rsa.

• This was the only thing in the entire internet that worked for me! – Yasiel Cabrera Sep 25 '20 at 1:47

use below command on your key it works on windows

icacls .\private.key /inheritance:r

• NB: These commands must be issued within a command window (CMD.EXE). The second command line would not work for me in a PowerShell command window; it would produce an error message saying 'Invalid parameter "%username%"', even though the environment variable USERNAME is defined an has the correct value. Also, after I invoked these two icacls commands on my RSA private key file, I continue to get the "bad permissions" error message when I invoke ssh in a PowerShell window. – Jim Fischer Aug 27 '20 at 20:18

This seems to be related to the version of OpenSSH you're running:

• where ssh returns:
%WinDir%\System32\OpenSSH\ssh.exe
%ProgramFiles%\Git\usr\bin\ssh.exe

ssh -V returns:
# %WinDir%\System32\OpenSSH\ssh.exe
OpenSSH_7.5p1, without OpenSSL

# %ProgramFiles%\Git\usr\bin\ssh.exe
OpenSSH_7.3p1, OpenSSL 1.0.2k  26 Jan 2017


When running ..\Git\usr\bin\ssh.exe, it works fine and doesn't complain about the permissions, but running ..\OpenSSH\ssh.exe comes back with the following, even though key ACLs are Full Access for myself and nothing else:

load key "t:\mykeys\rich-private.ppk": invalid format
banana@127.0.0.127: Permission denied (publickey).

• OpenSSH should not be installed to the Windows directory for whole host of reasons, from security, to it being a massive inconvenience should one need to fix a corrupted Windows directory either via DISM or using the Reset option (which has been improved to utilize the WinSxS directory versus reverting to the original install.esd). – JW0914 Jul 9 '18 at 19:40
• This is what helped me, I never got the windows ssh version to work in this scenario, only Git's :( – kutacoder Mar 7 '19 at 0:27
• This was also the fix for me. It seems Windows 10 Pro now bundles a pooched version of openssh. I was forced to remove the C:\Windows\System32\OpenSSH folder and add git's ssh.exe to PATH. – Shukri Adams May 23 '19 at 16:45
• This "fixed" it for me, using C:\Program Files\Git\usr\bin\ssh.exe works as C:\Windows\System32\OpenSSH\ssh.exe does not – smartins Nov 12 '19 at 9:12
• The error message is due to using an invalid key format [a PuTTY key], as OpenSSH doesn't support PuTTY keys (they must be converted first via PuTTYgen → Conversions) – JW0914 Jun 29 '20 at 12:57

You can use icacls in Windows instead of chmod to adjust file permission. To give the current user read permission and remove everything else:

Icacls <file name> /Inheritance:r


A single line in CMD might do the trick; as described here, adding the key from stdin instead of changing the permissions:

cat /path/to/permission_file | ssh-add -k


To check key has been added:

ssh-add -l


This is just a scripted version of @JW0914's CLI answer, so upvote him first and foremost:

# DO the following in powerhsell if not already done:
# Set-ExecutionPolicy RemoteSigned

# NOTE: edit the path in this command if needed
$sshFiles=Get-ChildItem -Path "$env:userprofile\.ssh" -Force

$sshFiles | % {$key = $_ & icacls$key /c /t /inheritance:d
& icacls $key /c /t /grant "${echo $env:username}":F & icacls$key /c /t /remove Administrator "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users
}

# Verify:
$sshFiles | % { icacls$_
}


I couldn't get any of these answers working for me due to permission issues, so I'll share my solution:

1. Go to %UserProfile%\.ssh
2. Copy and paste id_rsa, rename it to something else [example]
3. Open the renamed file [example] and replace the key with your own private key
4. cd to that directory
5. Enter your passphrase after issuing: ssh -i example example@127.0.0.1
• Please elaborate on "I couldn't get any of these answers working for me due to permission issues...", as there's at least four previous answers that permanently resolve permissions issues. – JW0914 Jul 2 '20 at 11:39
• @JW0914 Unfortunately I cannot recall the cause of my problem a month ago, much less 5 months ago. – isopach Jul 2 '20 at 12:05
• At least four other answers provide the exact same, or more, information that is in this answer, and it's simply not possible for any permissions issues to occur if any of those four answers were followed. – JW0914 Jul 2 '20 at 12:16
• @JW0914 You've already downvoted my answer man, what more do you want? – isopach Jul 2 '20 at 12:18
• The other options here did not work for me either (tried both through the GUI and multiple icacls methods). Comparing a working id_rsa file to one that it complained about (claimed 770 permissions), the permissions as shown in Windows were identical. A simple copy and paste in Explorer seemed to reset the permissions so did not work, but by using ROBOCOPY /COPYSEC (from an elevated command prompt) I was able to make a copy of a working key file, edit it to insert my new private key, and then this error went away. – Jimbly Sep 10 '20 at 22:33
1. Copy the public and private keys to %userprofile%\.ssh
2. Use the batch script below after finding your keys from the cmd prompt with where *.pub:
Md %Userprofile%\.ssh
Copy PublicKey %Userprofile%\.ssh
Copy PrivateKey %Userprofile%\.ssh

Cd %Userprofile%\.ssh
Icacls .\PublicKey  /Inheritance:r
Icacls .\PrivateKey /Inheritance:r

3. Right-click each file → Properties → Security:
Remove everyone except the user, setting the permissions for the user to Read
• Isn't the point of the script to avoid the last step? I don't understand – Ramhound Apr 18 '20 at 2:22
• To piggyback on @Ramhound's comment, how does this answer differ from at least four other answers showing the exact same thing via the GUI, CLI, and screenshots? – JW0914 Jul 2 '20 at 11:55
1. Download and unzip OpenSSH-Win64.zip (or Win32, depending on your system)
2. Execute FixUserFilePermissions.ps1 in PowerShell with administrator privilege
• The FixUserFilePermissions.ps1 script doesn't fix all permissions issues; for example, it will not fix permissions issues for an admin account that wouldn't be using %UserProfile%\.ssh (IIRC, an issue was opened for this - as of this writing, this has not been addressed in FixUserFilePermissions.ps1). The only way to guarantee correct file permissions is to use icacls (as of this writing). – JW0914 Jul 2 '20 at 12:05

Here's the way to do it using Microsoft's tooling, avoiding the problem from the get-go. But it should also fix the issue, meaning you can follow these instructions with existing keys.

Start PowerShell/Terminal as Administrator and run the following:

Install-Module -Force OpenSSHUtils -Scope AllUsers

# Make sure the service isn't disabled
Get-Service -Name ssh-agent | Set-Service -StartupType Manual

# We need this service as ssh-add depends on it
Start-Service ssh-agent

cat ~\.ssh\example-key.ecdsa | ssh-add -k -


Anonymous cowards press down to go down on me.

Use Mingw-w64.

Available here: https://github.com/mirror/mingw-w64

git clone https://github.com/mirror/mingw-w64


It also has other useful Linux commands like tar and gzip.

• How exactly does this even apply to the question being asked? – JW0914 Jul 2 '20 at 11:57
• @JW0914 It works around the issue. SSH with Mingw-w64 doesn't look at the key permissions and will allow you to connect with a machine readable key file. – Dallas Clarke Jul 3 '20 at 0:53
• What you're suggesting is simply insecure and would never be recommended. SSH keys should only be accessible by the user they belong too and no other user, group, or service... doing so negates the purpose of an SSH key. Please google the error message in the question or refer directly to OpenSSH's man pages. – JW0914 Jul 3 '20 at 11:20

I'm a Window user, using the Windows's bash and followed all the steps to set permission using Windows GUI, and it still doesn't work and it complains:

Permissions 0555 for 'my_ssh.pem' are too open.
It is required that your private key files are NOT accessible by others.


The I added sudo at the front of the ssh command and it just works. Hope this is helpful to others.

• But do you login to the server as yourself or as root? – G-Man Says 'Reinstate Monica' Nov 26 '19 at 6:56
• I run the Window bash terminal as myself, but I did 'Run as adminstrator' when I launch the Bash. – Alex Ramses Nov 26 '19 at 8:13
• sudo should not be used for an SSH session (please use a search engine to understand why - it's a security risk) and you're receiving the error because the permissions [0555] are incorrect. On BSD/Linux, the UGO privs must be 600 or 400. If you're trying to copy your key from Windows to WSL, this is not possible due to how the ACLs are set and maintained between Windows and WSL; instead, copy/paste the key's contents into a new file on WSL. – JW0914 Jul 2 '20 at 12:12

I had the same problem on Windows 10, and it arouse when I created a second user account on my machine.

Since that new user was also an administrator and It had access to my user folder, I did these steps to limit the access on my .ssh folder and it worked!

1. Navigate to your user folder at C:\Users\YOU
2. Right click on .ssh/ folder to open context menu
3. Under Give access to... sub-menu, select Remove access
4. Done!

Now try to log back in to your remote computer using ssh!

Hope it helps someone!

• How does this differ from the other answers which indicates the key permissions must be modified to only include the one user that intends to use. – Ramhound May 15 '20 at 23:21
• it seemed a little more straight forward, so I thought I share it. – khalifmahdi May 16 '20 at 0:14
• @khalifmahdi How exactly is this more straightforward? Two answers provide screenshots, whereas at least two others provide copy/paste commands for a terminal – JW0914 Jul 2 '20 at 12:13

Answer by iBug works fine! You can follow that and get rid of this issue.

But there are few things which are needed to be cleared as I faced issues during setting up permissions and it took few minutes for me to figure out the problem!

Following iBug's answer, you'll remove all the permissions but how do you set Full Control permission to yourself? that's where I got stuck at first as I didn't knew how to do that.

After Disabling Inheritance, you'll be able to delete all allowed users or groups.

Once Done with that,

Click on Add then click on Set a Principal then enter System and Administrators and your email addredd in the field at bottom then click on check names.

It'll load the name if user exists. Then, Click on OK > Type Allow > Basic Permisisons Full Control > Okay

This will setup Full Control permission to SYSTEM, Administrators and Your User.

After that try to ssh using that key. It should be solved now.

I had same issue and I solved that using this method. If there's any user or group with that name then it'll load that.

-Screenshots-

• How does this answer differ from at least four other answers showing the exact same thing via the GUI, CLI, and screenshots? – JW0914 Jul 2 '20 at 12:14
• The answer I followed was causing issues which I clarified properly here(probably)! I wrote this 1.5 years ago! (Luckily I moved to Linux just a month after that) Exact same thing can be done in many ways obviously but that doesn't mean one shouldn't mention the other way round. – lazycipher Jul 5 '20 at 19:08