(Note post is first draft)
Just ran into this tonight, setting up a new machine to actually run Ubuntu Bash via WSL. I was trying to use git in the WSL ubuntu shell and use ssh keys. Also found that after running ssh-keygen, ssh was now complaining that the keys were too public. Easy fix: chmod 400 .ssh/id_rsa right?
Ah yeah, not working! Sigh. Okay, so wtf? So I start investigating and to make things more annoying, apparently WSL seems to setup two different home directories. Arg! Somebody didn't think this through and now I have a Windows home directory and a WSL Ubuntu home directory.
TBH, having a unified home directory for bash and Windows is actually a standard practice by MinGW (and cygwin too, I believe) and Git for Windows installations. They basically merge the concept of your home directory (ie, "cd ~") between Windows/bash. This is best too, especially for your ssh keys and other things like configurations you want backed up, etc.
Now I only tried this so far with Ubuntu bash under WSL, so not sure if the Debian distro or others have this problem but from the short bit of searching revealed they might be in the same boat for the time being until somebody managing the WSL installations of Ubuntu/Debian/etc finally realize that they shouldn't actually be separate. (Note, there definitely was issues in the past, prior to DrvFS metadata sync with NTFS ACLs, however they have DrvFS properly syncronizing commands like chmod 400 with proper NTFS ACLs that match the intention.)
First off, you want to copy your bash profile config into your windows home directory:
cd %USERPROFILE%\AppData\Local\Packages\Canonical[tab]\LocalState\rootfs\home\{username}
For instance, mine looked like this:
C:\Users\Eric\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\eric>dir
Volume in drive C has no label.
Volume Serial Number is 4CE0-4086
Directory of C:\Users\Eric\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\eric
02/17/2019 12:29 AM <DIR> .
02/17/2019 12:29 AM <DIR> ..
02/16/2019 02:16 AM 3,771 .bashrc
02/17/2019 12:38 AM 546 .bash_history
02/16/2019 02:16 AM 220 .bash_logout
02/17/2019 12:29 AM <DIR> .local
02/16/2019 02:16 AM 807 .profile
02/17/2019 12:29 AM <DIR> .ssh
02/16/2019 02:17 AM 0 .sudo_as_admin_successful
Now you want to copy some of these files into your Windows home directory, under %USERPROFILE% which is usually C:\Users\{username}. In my case, thats C:\Users\Eric
So now we copy .bashrc and .profile into Windows:
copy .bashrc %USERPROFILE%
copy .profile %USERPROFILE%
In my case, I had some ssh keys in .ssh that I definitely wanted syncronized between everything, so I copied the contents of that folder into my Windows home directory as well: (Note xcopy /i makes it assume that .ssh is a directory at the destination if its not there already)
xcopy /s /i .ssh\* %USERPROFILE%\.ssh
But wait... there's more!
Remap Home Directory
[Remap home directory in WSL:
link]
Ok, so the problem you'll have now, if you run bash, its that the login process isn't looking in your Windows home directory still, so you have to map that properly. This is just like the standard distros: simply edit the /etc/passwd file to map your login's home directory to /mnt/c/Users/{username}.
sudo nano /etc/passwd
(make changes/save/exit nano)
logout
Now you can reload the WSL bash again. I usually just type "bash".
At this point in time (2018-Feb-17), WSL doesn't seem to default to the correct DrvFS parameters to make sure chmod actually sets the underlying NTFS ACLs properly, so we have to make the WSL configure this correctly. You do this by create/edit of the file /etc/wsl.conf Note, this file may not exist already, and TBH it didnt exist for me so I created it.
bash #if not already running in bash
sudo nano /etc/wsl.conf
Add the following into that new file if just created (make appropriate edits if it already exists). NOTE dont use the article's `root = /windir/` thats not a good thing unless you really want to start deviating from the "standard" WSL
#Let’s enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=11"
mountFsTab = false
#Let’s enable DNS – even though these are turned on by default, we’ll specify here just to be explicit.
[network]
generateHosts = true
generateResolvConf = true
Now you save/exit nano and restart bash.
So in my case, my ssh keys can now be properly set to 400 via chmod and ssh will stop complaining about my private key being too public!
bash cd ~/.ssh chmod 400 id_rsa ls -al ~/.ssh total 8 drwxr-xr-x 1 eric eric 512 Feb 17 00:41 . drwxr-xr-x 1 eric eric 512 Feb 17 00:58 .. -r-xr--r-- 1 eric eric 46 Feb 17 00:29 config -rwxr--r-- 1 eric eric 803 Feb 17 00:24 known_hosts -r-------- 1 eric eric 1679 Feb 17 00:22 id_rsa -r-------- 1 eric eric 394 Feb 17 00:22 id_rsa.pub # worked! okay try ssh now: ssh -vvv git@github.com # (success! ah yeah)
All right. Hope that helps somebody else!
|
|