Musings of Geekdom by Eric Newton

tail /var/log/thoughts
posts - 88 , comments - 41 , trackbacks - 68

Sunday, February 17, 2019

WSL, git, ssh keys, and a partridge in a pear tree

(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.) 

For starters, make sure you have Windows Subsystem for Linux installed, and choose your favorite (available) distro.  In my case, I'm using the Ubuntu distro.

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:

 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)

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.

Note, I used the following article as a reference: Automatically Configuring WSL

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
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.
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!

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
# worked! okay try ssh now:
ssh -vvv
# (success!  ah yeah)

All right.  Hope that helps somebody else!

Posted On Sunday, February 17, 2019 1:51 AM | Comments (0) | Filed Under [ wsl windows-subsystem-for-linux ubuntu bash git git-for-windows ssh ]

Ajax Post on Safari 11.4 timing out for strange reasons? Check here

This was a little doozy.

We have a site that has ajax file upload fields that worked for all browsers, IE, Firefox, Chrome, Safari except for one instance: Safari on iPhones.

How strange!  The problem exhibited was that Safari would start the request but never seem to attempt to finish and no matter what timeout, would timeout after 60 seconds (the max I believe you can set).  Note that using a traditional POST would work fine, but who wants that in 2018/2019???

Turns out there's an odd little bug in Safari on iOS 11.4... if you have input type=file with no file selected, Safari sets up to upload zero bytes, and just does nothing.

The fix is a bit odd too... when you have an <input type=file> field with no file selected, you need to use new FormData() to remove it before submitting the request.

[sample code to come]
basically check the field via javascript before ajax post, examine the size property.  If its 0, you now know that there's no file selected, so you have to remove that field from the FormData collection.

Seems to have been fixed after iOS 11.4.

Posted On Sunday, February 17, 2019 1:10 AM | Comments (0) | Filed Under [ ios safari jQuery timeout ajax ]

Powered by: