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.

What about windows?

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

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


Microsoft Windows [Version 6.1.7601]


C:\>ssh [email protected] -i private-key.ppk
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.
Load key "private-key.ppk": bad permissions
[email protected]: Permission denied (publickey).

C:\>ssh [email protected] -i private-key.ppm
Warning: Identity file private-key.ppm not accessible: No such file or directory.
[email protected]: Permission denied (publickey).


18 Answers 18


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:

enter image description here

  • 6
    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, 2018 at 15:10
  • 48
    Actually, I did that and it still complains that 0777 permissions are too open. Sep 4, 2018 at 8:25
  • 105
    Why is this so difficult on windows, can someone just add a --ignore-stupid-rule command option? Dec 20, 2018 at 20:57
  • 1
    Stupid, i don't have the permessions to do that..-_-
    – Kuronashi
    Nov 29, 2019 at 12:15
  • 4
    I still get: Permissions 0770 are too open
    – Buntel
    May 13, 2020 at 21:17

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

  • GUI:
    [File] PropertiesSecurityAdvanced
    1. Owner: Change → Select a principal → Enter key's user → OK
    2. Permission Entries: Remove all except for the key's user
    3. Set key's user to Full Control if not already set
      1. Select user → Modify → Full Control → OK
      2. Add → Select a principal → Enter key's user → OK
    4. OK → OK

  • Cmd:
    ::# Set Key File Variable:
        Set Key="%UserProfile%\.ssh\id_rsa"
    ::# Remove Inheritance:
        Icacls %Key% /c /t /Inheritance:d
    ::# Set Ownership to Owner:
        :: # Key's within %UserProfile%:
             Icacls %Key% /c /t /Grant %UserName%:F
        :: # Key's outside of %UserProfile%:
             TakeOwn /F %Key%
             Icacls %Key% /c /t /Grant:r %UserName%:F
    ::# Remove All Users, except for Owner:
        Icacls %Key% /c /t /Remove:g "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users
    ::# Verify:
        Icacls %Key%
    ::# Remove Variable:
        set "Key="

  • PowerShell:
    # Set Key File Variable:
      New-Variable -Name Key -Value "$env:UserProfile\.ssh\id_rsa"
    # Remove Inheritance:
      Icacls $Key /c /t /Inheritance:d
    # Set Ownership to Owner:
      # Key's within $env:UserProfile:
        Icacls $Key /c /t /Grant ${env:UserName}:F
       # Key's outside of $env:UserProfile:
         TakeOwn /F $Key
         Icacls $Key /c /t /Grant:r ${env:UserName}:F
    # Remove All Users, except for Owner:
      Icacls $Key /c /t /Remove:g Administrator "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users
    # Verify:
      Icacls $Key
    # Remove Variable:
      Remove-Variable -Name 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, 2018 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, 2018 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, 2018 at 18:40
  • 20
    this should be correct answer. Thanks for CLI options. GUI always sucks in windows case. Apr 30, 2019 at 20:51
  • 2
    On Windows10 I get Invalid parameter "/grant" I had to add :r with a space Icacls $Key /c /t /grant :r $env:UserName:F Aug 19, 2021 at 9:08

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

  • 5
    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, 2019 at 18:03
  • 8
    Best answer. When using ubuntu shell on Windows, the advise about safety of the root access is totally irrelevant Apr 5, 2020 at 1:19
  • 3
    @DmitryTorba Please explain, as that makes zero sense and is factually inaccurate.
    – JW0914
    Jun 27, 2020 at 10:51
  • 5
    This worked for me. I did the above solutions and was still getting the 0077 warning but this fixed it.
    – Timaayy
    Sep 7, 2020 at 22:07
  • 3
    @TimotheeLegros That's because you're running the SSH session as root which is never recommended as it's a security risk (the only exception is on a single user OS, which Ubuntu is not). I explained this in the first comment and a simple Google search can provide real world examples of why this should never be done. You must copy the SSH keys from Windows to WSL if you want the files to have UGO permissionsz else they'll still have Windows ACLs. If it's worth doing, it's worth doing right the first time
    – JW0914
    Oct 16, 2020 at 8:57

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>
  • 2
    Best answer here. Aug 31, 2020 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, 2020 at 14:37
  • At least in Linux and Mac the ssh final part is not necessary, chmod 600 on the ppk file and then sftp connection works. see stackabuse.com/…
    – Dr Potato
    Mar 24, 2021 at 15:07
  • THANK YOU, this was making me absolutely miserable, you've restored my faith in humanity and made me a better dev Apr 20, 2021 at 20:34
  • 2
    Git-Bash would also do the job straight out-of-the-box. Sep 1, 2021 at 5:03

You just need to do at least four things:

  1. Disable inheritance

enter image description here

  1. Convert inherited permissions to explicit permissions

enter image description here

  1. Remove Users group

enter image description here

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

enter image description here

  • This was the only thing in the entire internet that worked for me! Sep 25, 2020 at 1:47
  • what does step 4 mean? Can you elaborate on what "this should be enough to add id_rsa." means? Aug 15, 2021 at 7:00
  • 2
    this is the simplest answer! on the key file: (1) disable inheritance, (2) add only 1 user (current user) with Full Permission
    – Dan D.
    Aug 23, 2022 at 13:02
  • this worked for me, but only when removing authenticated users as well
    – LeonardoX
    Oct 21, 2022 at 7:12

use below command on your key it works on windows

icacls .\private.key /inheritance:r
icacls .\private.key /grant:r "%username%":"(R)"
  • 4
    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. Aug 27, 2020 at 20:18
  • 1
    doesn't worth either, still gives "Permissions for '' are too open." Aug 15, 2021 at 7:03
  • 1
    a Non-administrator cmd.exe prompt Aug 20, 2021 at 2:09
  • 1
    results in: -r--r--r-- 1 xxx xxx xxx xxxxxxxx id_rsa but we want -rwx------
    – rundekugel
    Jan 24, 2022 at 9:37

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
Icacls <file name> /Grant:r "%Username%":"(R)"
  • 2
    Thanks worked like charm Jul 17, 2021 at 15:12
  • still says Permissions for are too open. Aug 15, 2021 at 7:06
  • Worked for me. Maybe the wildcard can lead to more than one account getting granted access which could then cause ssh to complain. Oct 9, 2021 at 23:10
  • Duplicate from "answered Oct 4 '19 at 13:28 Walter Ferrao"
    – rundekugel
    Jan 24, 2022 at 9:41

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

  • where ssh returns:
    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
  [email protected]: 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, 2018 at 19:40
  • This is what helped me, I never got the windows ssh version to work in this scenario, only Git's :(
    – guychouk
    Mar 7, 2019 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. May 23, 2019 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, 2019 at 9:12
  • 2
    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, 2020 at 12:57

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 -
  • 1
    Holy moly, this actually worked for me, after MUCH frustration (even though I encountered errors with the Install-Module step). I am eternally grateful.
    – Gershy
    Dec 2, 2021 at 20:38
  • Can't even find the -k switch in the ssh-add man page... edit: Found it in the Arch-version: man.archlinux.org/man/ssh-add.1.en
    – toraritte
    Jan 8, 2023 at 20:46
  • OpenSSHUtils has been deprecated :( Feb 12, 2023 at 19:08

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 $_
  • You don't need to enumerate each file individually, you can process the directory directly. Apr 3, 2023 at 4:34
  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
      Icacls .\PublicKey  /Grant:r "%Username%":"(F)"
      Icacls .\PrivateKey /Grant:r "%Username%":"(F)"
  3. Right-click each file → Properties → Security:
    Remove everyone except the user, setting the permissions for the user to Read
  • 2
    Isn't the point of the script to avoid the last step? I don't understand
    – Ramhound
    Apr 18, 2020 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, 2020 at 11:55

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 [email protected]
  • 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, 2020 at 11:39
  • @JW0914 Unfortunately I cannot recall the cause of my problem a month ago, much less 5 months ago.
    – isopach
    Jul 2, 2020 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, 2020 at 12:16
  • 1
    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, 2020 at 22:33
  • 1
    This solved my problem
    – 時雨初
    Mar 23, 2022 at 7:54
  1. Download and unzip OpenSSH-Win64.zip (or Win32, depending on your system)
  2. Execute FixUserFilePermissions.ps1 in PowerShell with administrator privilege
  • 1
    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, 2020 at 12:05

Use Mingw-w64.

Infos: http://mingw-w64.org/doku.php

Download with Git for Windows, or directly.

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, 2020 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. Jul 3, 2020 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, 2020 at 11:20

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.


Permission Entries Select a Principal/ Select User or Groups

  • 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, 2020 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, 2020 at 19:08

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? Nov 26, 2019 at 6:56
  • I run the Window bash terminal as myself, but I did 'Run as adminstrator' when I launch the Bash. Nov 26, 2019 at 8:13
  • 1
    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, 2020 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!

  • 3
    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, 2020 at 23:21
  • it seemed a little more straight forward, so I thought I share it. May 16, 2020 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, 2020 at 12:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .