11

I have .pem file located on local disk C "c/private-key.pem" And I have a soft link to it on Ubuntu subsystem "~/.ssh/private-key.pem -> /mnt/c/private-key.pem"

And when I'm trying to shh some remote machine from Ubuntu subsystem, I got :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/artur/.ssh/private-key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/artur/.ssh/private-key.pem": bad permissions
Permission denied (publickey).

It was started after 1803 update for Windows.

I was trying to use chmod 400 for key on C drive and in ./ssh folder on subsystem. And was trying to set owner just to me and remove all other users from security panel on Windows for this file key. But i got "Permissions XXXX for '/home/artur/.ssh/private-key.pem' are too open" or "Permission denied" all the time.

Can any body help me and explain how keys permissions should be configured on Windows and Ubuntu subsystem?

  • 1
    I also tried chmod 400 for key on subsystem and set owner just to me from windows security. But the issue still remains same. someone please help. This happened to me with the recent windows 10 update. – sith May 10 '18 at 5:02
  • Is this your issue github.com/Microsoft/WSL/issues/3181? – Biswapriyo May 14 '18 at 19:37
7

Solution that works for me in windows WSL (without changing file mode):

sudo ssh -i keyfile <user>@ip
  • 4
    I don’t understand.  Can you explain what you mean?  Please do not respond in comments; edit your answer to make it clearer and more complete. – Scott May 24 '18 at 7:26
  • 1
    If WSL still shows access permissions for group and others, this is not an acceptable solution. SSH keys must only be accessible to the user they're intended for and no other user or group. Allowing for anything other the 600/400 permissions defeats the purpose of utilizing an SSH key, as it compromises the security of said key. – JW0914 Aug 11 '18 at 12:40
  • I have no clue how this works, but, this solution works. It may not be the ideal solution(using sudo to ssh, -_-), but, it worked. Some update had messed it up for few months already! Hope it gets fixed. – bozzmob Aug 21 '18 at 14:57
  • 1
    I found the right answer here - superuser.com/a/1323647/352182 You cannot modify a file inside of /mnt (windows file system), copy the file to your linux and then it works as expected. – bozzmob Aug 21 '18 at 15:00
  • I agree with @JW0914, doing this compromises the security of the key. JW0914's answer should be the accepted answer. – jtcotton63 Jun 12 at 18:17
4

Copy the SSH key over to your WSL ~/.ssh directory, as an SSH key with anything other than 600/400 permissions compromises the key.

  • Once the key is copied over, ensure it's EOLs have been changed to LF.

    • There's a number of ways to do so, from the Atom text editor to CLI solutions like dos2unix, unix2dos, etc.
  • See @simpleuser's answer below to understand why permissions cannot be changed via Windows, of which necessitates copying the key to the WSL's ~/.ssh directory

  • This should be the accepted answer. – jtcotton63 Jun 12 at 18:18
3

I'm reading between the lines, and assuming you're using a Linux subsystem in Windows 10. When you symlinked the Windows file from C:\ into the Linux file system in $HOME/.ssh, the permissions of the actual file are still under control of Windows, and the permissions shown to you in the Linux window just best represent the Windows permissions; you can't change the permissions on the Windows files in /mnt/c from Linux. This FAQ from Microsoft talks about how files are handled in the two overlapping file systems.

The file you need to change the permission on is the file the symlink is pointing so, so that means the file in /mnt/c

It doesn't seem possible to give user-only access to a Windows file. Even if you disable permission inheritance on a file and give only your own user read permission, the Linux permissions still show as -r--r--r--, so that won't be usable for .ssh

The only option appears to be copying the file from Windows into Linux, at which point you can use chmod and chown on it.

-1

To expand on the answer above as it works perfectly for me.

I am using Linux Windows Shell on Windows 10 Pro.

The 1803 update broke SSH in the shell as there is no equivalent to chmod 600 within windows.

but you can leave your pem unchanged with file permission 777 and run

sudo ssh -i  my777Keyfile.pem  ubuntu@12.34.45.78 

and now you will log straight in. (Not sure why though).

  • Did you test your answer? I used the GUI in Windows to change the icacl but after some experimentation I couldn't match the Linux SSH requirement that it's restricted down to the ssh user. From memory I always needed to be in at least one group. This meant that I could restrict to (500 or 540 I think) but that still won't work. If I get chance I'll experiment with your method of moving the key to the .shh directory in WSL as that would be a simple and effective solution. – Chris B Aug 2 '18 at 11:59
  • I've used both methods in my answer, however I did state I've never used WSL (it's a security nightmare). If WSL does not allow to restrict group & others' permissions on Windows' side down to just the key's user(s), then WSL configures Windows file system access in a similar way as Android on internal/external SD cards (non-customizable 771 permissions due to how ext4 and NTFS configure access permissions). Allowing access to the key by any but the user defeats the purpose of SSH keys, most especially if a user hasn't encrypted the key with a secure password. – JW0914 Aug 2 '18 at 13:38
  • Since you implied the first two steps in my answer didn't work for you, I've removed them, leaving the last, and only, solution, as SSH keys should never be readable or accessible to any but the user they're intended for. – JW0914 Aug 4 '18 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.