Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't SSH from WSL #3181

Closed
ArturChe opened this issue May 11, 2018 · 30 comments

Comments

Projects
None yet
@ArturChe
Copy link

commented May 11, 2018

  • Your Windows build number: Microsoft Windows [Version 10.0.17134.1]

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 or 600 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.

Also I made a copy of key in Ubuntu subsystem which now located at c:\Users\<WindowsUserName>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\<UbuntuUserName>\.ssh\ and was trying to manage permissions and owners of it. And it fails too!

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

@WSLUser

This comment has been minimized.

Copy link

commented May 11, 2018

Yeah there have been changes with build 17134. You want to review this blog: https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/ and see if that helps.

@ArturChe

This comment has been minimized.

Copy link
Author

commented May 11, 2018

@DarthSpock Yeap, it helps but partially. I mean now I can connect my remote machine using the ssh config file, which contains the given key to the destination machine (a soft link to a file on C drive). But can't connect from connected machine to another Permission denied (publickey). Config file contains other soft links to key files. All keys has same permissions and owners (a Windows permissions and owners and chmod on Ubuntu subsystem).

Also I can't connect to the first machine when i try ssh -i .ssh/private-key.pem remote_machine_addr Permission denied (publickey). That connection completely the same that I have in config file!?!?

Damn, I'm confused. How can I define which permissions and owners should be set on Windows and what i should do on Ubuntu subsystem (chmod, chgrp, or what ....)

@WSLUser

This comment has been minimized.

Copy link

commented May 11, 2018

@aseering might be able to provide more assistance

@morgan-greywolf

This comment has been minimized.

Copy link

commented May 13, 2018

You might also try using pageant (from PuTTY) as your ssh keystore and then use weasel-pageant (here on github) in place of ssh-agent. This has side benefits if you also msys or Win32 Emacs.

@archer0001

This comment has been minimized.

Copy link

commented May 14, 2018

I discovered that if my keys were in a non WSL location, I had to mount the drive it was on with -o metadata. Once I did that, I could chmod -R og= key dir to get the permissions to a state where ssh accepted them.

Be sure to update wsl.conf so that the mount changes persist.

@WSLUser

This comment has been minimized.

Copy link

commented May 14, 2018

Ah ok, I see that there are multiple issues including this one that stem from a root cause: #2770

@ArturChe

This comment has been minimized.

Copy link
Author

commented May 14, 2018

Nothing helps for now: i have tried to mount C drive with -o metadata and get the chmod: changing permissions of 'private-key.pem': Operation not permitted unfortunately.

@archer0001

This comment has been minimized.

Copy link

commented May 14, 2018

even with sudo? intriguing!

@ArturChe

This comment has been minimized.

Copy link
Author

commented May 14, 2018

With sudo chmod 600 or 400 I get Permission denied (publickey) trying to establish ssh connection.

@ArturChe

This comment has been minimized.

Copy link
Author

commented May 17, 2018

I have copied keys from Windows to Ubuntu subsystem and applied chmod 400 for each key file even without sudo.
It works for me now.
But I'd like to use previous behavior, when key placed on one location on Windows and on subsystem I manipulate with soft links only.

@Biswa96 I haven't try your proposal so far...

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented May 25, 2018

@Biswa96 I haven't try your proposal so far...

Do NOT spelunk into the Linux filesystem using Windows apps and tools. Try mounting with -o metadata and see if you can coerce it into accepting the 0400 mode.

@atorstling

This comment has been minimized.

Copy link

commented May 30, 2018

I think I figured out why this happens. In the ssh source you can see that ssh only blocks overly permissive key files if they are owned by the current user. Since DrvFs files used to be listed as owned by root, ssh would allow any key file from a DrvFs drive. With the recent changes, the files are listed as owned by the current user, and suddenly the check applies.

Luckily, as mentioned above, you can just remount with the -o metadata option and chmod your key files to be less permissive.

@sunilmut

This comment has been minimized.

Copy link
Member

commented May 30, 2018

Here is the blog post on how to use the -o metadata option.

@sunilmut sunilmut closed this May 30, 2018

@reijin90

This comment has been minimized.

Copy link

commented Jun 5, 2018

Sorry to re-open this, but my Linux doesn't seem to want to set the permissions:

➜  ~ ll windat/documents/keys/
total 4.0K
-rwxrwxrwx 1 USER USER 1.7K May  4 11:40 google
-rwxrwxrwx 1 USER USER  391 May  4 11:40 google.pub
➜  ~ sudo umount /mnt/c
[sudo] password for USER:
➜  ~ sudo mount -t drvfs C: /mnt/c -o metadata
➜  ~ chmod 0600 windat/documents/keys/google
➜  ~ ll windat/documents/keys/
total 4.0K
-rwxrwxrwx 1 USER USER 1.7K May  4 11:40 google
-rwxrwxrwx 1 USER USER  391 May  4 11:40 google.pub

➜  ~ mount -l
rootfs on / type lxfs (rw,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
none on /dev type tmpfs (rw,noatime,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)
none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)
none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)
none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)
none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noatime)
D: on /mnt/d type drvfs (rw,noatime,uid=1000,gid=1000)
E: on /mnt/e type drvfs (rw,noatime,uid=1000,gid=1000)
F: on /mnt/f type drvfs (rw,noatime,uid=1000,gid=1000)
G: on /mnt/g type drvfs (rw,noatime,uid=1000,gid=1000)
C: on /mnt/c type drvfs (rw,relatime,metadata)

Here are my permissions on Windows:

D:\data\Documents\keys
λ  Get-Acl .\google | Format-List


Path   : Microsoft.PowerShell.Core\FileSystem::D:\data\Documents\keys\google
Owner  : DESKTOP-ENBN1LT\USER
Group  : DESKTOP-ENBN1LT\USER
Access : DESKTOP-ENBN1LT\USER Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  FullControl
         NT AUTHORITY\Authenticated Users Allow  Modify, Synchronize
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : XXXX

Any ideas?

@ArturChe

This comment has been minimized.

Copy link
Author

commented Jun 5, 2018

I don't know why does @sunilmut CLOESED the issue, but I previously sad that I have tried to mount disk with -o metadata option and it DOES NOT resolving the issue!

@WSLUser

This comment has been minimized.

Copy link

commented Jun 5, 2018

Try configuring it in wsl.conf instead of the command-line method. Here's the blog: https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/

@reijin90

This comment has been minimized.

Copy link

commented Jun 5, 2018

Ok, setting it in /etc/wsl.conf fixed it for me.
Just create the file if its not there and enter the following code:

[automount]
options = "metadata"

Then exit out of all the instances and relaunch WSL. All drives should be mounted with metadata now (see mount -l)

The blog post linked by @DarthSpock also contains other useful configs, so it's worth a look.

Edit: @ArturChe I think this issue should be renamed include "chmod" or sth.

@atorstling

This comment has been minimized.

Copy link

commented Jun 5, 2018

Just to add to what @reijn90 said: Lately WSL requires some funky killall command to be properly restarted. See https://superuser.com/q/1126721. Unless someone here can enlighten us about the proper way of restarting, that is :D

@WSLUser

This comment has been minimized.

Copy link

commented Jun 5, 2018

WSL requires some funky killall command

You can use Task Manager to forcibly kill any Linux processes running includinginit to forcibly tear the session down. Just be sure all instances are removed before creating a new one.

@AceHack

This comment has been minimized.

Copy link

commented Nov 30, 2018

I'm having this same problem, none of the above fixed it, please re-open

@donglixp

This comment has been minimized.

Copy link

commented Dec 30, 2018

The same problem.

@reijin90

This comment has been minimized.

Copy link

commented Dec 30, 2018

@AceHack @donglixp
No one can help you without any additional information. Here is how a good comment to receive actual help looks like:
-Include commands and output of what you did
-include mount -l output

That way others can actually help you. "Stating it doesn't work" helps no one and just discourages help because helpers need to painstakingly gather information from you. Give information so ppl can help you.

@MostHated

This comment has been minimized.

Copy link

commented Mar 30, 2019

I think I figured out why this happens. In the ssh source you can see that ssh only blocks overly permissive key files if they are owned by the current user. Since DrvFs files used to be listed as owned by root, ssh would allow any key file from a DrvFs drive. With the recent changes, the files are listed as owned by the current user, and suddenly the check applies.

Luckily, as mentioned above, you can just remount with the -o metadata option and chmod your key files to be less permissive.

This comment helped me get it working today. I was kicking myself in the face trying to figure out why it kept giving permission errors when I was only ever working just as my user, but I checked the ownership of ~/.ssh/config and ~/.ssh/id_rsa and sure enough, they were owned by root:root while everything else was as my user. So I just did sudo chown myuser:myuser ~/.ssh/config and the id_rsa and everything worked great.

@strarsis

This comment has been minimized.

Copy link

commented Apr 18, 2019

I got the same issue (too open permissions for the private key file located on the drvfs mount).
The metadata option was already set, so this doesn't fix the issue for me.
What can be done? Should the private key be placed in user home (WSL) and used instead for ssh login?

@WSLUser

This comment has been minimized.

Copy link

commented Apr 19, 2019

@strarsis did you configure the permissions that should be used by default in the metadata option? If not, then do a chmod to 0644 and it should apply. But you need to set it in wsl.conf if you want it to persist between WSL terminal sessions if you want to set the metadata option.

@strarsis

This comment has been minimized.

Copy link

commented Apr 20, 2019

@WSLUser: The metadata option was already set in /etc/wsl.conf.
I used chmod 0644 on the private key file and also ensured with
chown myuser:myuser it belongs to the terminal user.
The permissions of the private key file hadn't changed though (-rwxrwxrwx),
they don't correspond to 0644, they aren't applied onto the file, even with metadata option.

@strarsis

This comment has been minimized.

Copy link

commented Apr 20, 2019

@WSLUser:
/etc/wsl.conf:

[automount]
enabled = true
root = /
options = "metadata,umask=22,fmask=11"
mountFsTab = true
@WSLUser

This comment has been minimized.

Copy link

commented Apr 21, 2019

Configure fstab for both / and /mnt/c

@ricardotominaga

This comment has been minimized.

Copy link

commented May 4, 2019

I followed the "metadata" procedure aforementioned,

"sudo chmod 600 key",

and "sudo ssh -i key user@ip"

Solved for me...

@benitogf

This comment has been minimized.

Copy link

commented Jun 3, 2019

using ssh.exe instead of ssh solved it for me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.