SSH key and the »Windows Subsystem for Linux«

With Bash on Ubuntu on Windows, you can use a Windows Subsystem for Linux on Windows 10. With that, you can run many Linux commands, for example, ssh. This post shows you how to create an SSH key, which should be used on both, the Linux subsystem and Windows.

Update from May 14, 2018: After updating to the Insider Build 17063, you need to run the following commands on the Windows Subsystem for Linux to make the solution work again, as Entity Black points out in his comment under this post:

sudo umount /mnt/c
sudo mount -t drvfs C: /mnt/c -o metadata 

Goal

I wanted to create an SSH key, which I can use with the Linux subsystem and standard Windows programs. In the best scenario, the key is stored only once on the hard disk. You can read a tutorial about installing the subsystem on howtogeek.com.

Solution

The default path for SSH keys on Windows is C:/Users/Florian/.ssh which matches the path /mnt/c/Users/Florian/.ssh on the Linux subsystem. Default SSH path on the subsystem is ~/.ssh.

Previous to this post update, I had a not optimal solution where the keys needed to exist twice. But in the comments there were several folks with better solutions – one of them Andrey Chirkov, who posted a one-line solution that you run on the Windows Subsystem for Linux (the ~/.ssh folder must not exist before running it):

ln -s /mnt/c/Users/Florian/.ssh ~/.ssh

That creates a link from ~/.ssh to /mnt/c/Users/Florian/.ssh. With that, we only need to store our SSH keys in the Windows path and can use them from the Linux shell, too.

After trying it, I noticed that this line was also part of the Stack Overflow response I linked in the previous version of the post. I have no idea why I did not get it working back then…

The original version of this post was published on March 8, 2017.

Related posts

15 comments on »SSH key and the »Windows Subsystem for Linux««

  1. Doug

    Thanks!

    I also found I could copy existing Windows keys and then fix up the permissions with:

    chmod 600 ~/.ssh/id_rsa
    chmod 644 ~/.ssh/id_rsa.pub
    Reply
  2. Charles Gaydon

    Thank you for your help ! Your article helped me to figure out how the whole ssh system worked.
    Just one thing : the private and public keys were created in the root/.ssh directory in my case, and not in the user directory. But I use the Linux subsystem for Windows, so that can be an explanation.

    Reply
  3. Daniel Lee

    Have you tried hard-linking the files rather than using a symbolic link? I think the permissions would be preserved in that case.

    Reply
  4. Entity Black

    This works for me and I have just one key 😉

    ```
    ssh-keygen -t ecdsa -C "" -f /mnt/c/Users//.ssh/
    touch ~/.ssh/config
    vi ~/.ssh/config
    ```

    **paste:**

    ```
    Host *
    IdentityFile /mnt/c/Users//.ssh/id_ecdsa
    ```

    **save config**

    ```
    chmod 600 ~/.ssh/config
    chown $USER ~/.ssh/config

    touch /mnt/c/Users//.ssh/known_hosts
    ln -s /mnt/c/Users//.ssh/known_hosts ~/.ssh/known_hosts
    ```

    Reply
  5. Miha

    Guys have you tried multiple ssh keys ?

    I have 2 keys,

    home_rsa
    work_rsa

    but even if I modify the config file, they do not get picked up, I always have to rename it to id_rsa for git clone to work.

    Anyone else noticed this problem?

    Reply
  6. Miha

    Hi Florian,

    thanks for the link, that solved the issue. Indeed the default SSH Agent does not work so well with multiple keys.

    Best,

    Miha

    Reply
  7. Entity Black

    Important update,
    based on latest update "Insider Build 17063" there has been significant change in permissions. In very short, you need to:

    sudo umount /mnt/c
    sudo mount -t drvfs C: /mnt/c -o metadata

    Relevant links:
    https://github.com/Microsoft/WSL/issues/3181
    https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/
    https://blogs.windows.com/windowsexperience/2017/12/19/announcing-windows-10-insider-preview-build-17063-pc/#cbUAtBrErr1A3JJA.97

    Reply

Leave a Comment

Your email address will not be published. Required fields are marked *