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 

Update from May 29, 2018: It seems that the steps with unmounting are only temporary, as pointed out in the comments. To fix this, you need to modify or create a config file and add a little bit of content to it. There are three slightly different ways proposed in the comments – one by Andrew, one by Entity Black, and one by Vince.


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


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

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

  1. Doug


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

    chmod 600 ~/.ssh/id_rsa
    chmod 644 ~/.ssh/
  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.

  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.

  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


    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

  5. Miha

    Guys have you tried multiple ssh keys ?

    I have 2 keys,


    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?

  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.



  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:

      1. Andrew

        Does unmounting and mounting solves the issue for you? For me it doesn't set the metadata flag. Any ideas?

      2. Andrew

        I found the solution.
        Since I wasn't able to mount c: with metadata flag I had to change /etc/wsl.conf and include the following:
        options = "metadata"

  8. Vince

    It worked once after unmounting and remounting drive C. When I exit and re-enter the shell, I'm once again unable to use git.

    This isn't a workable solution for me. I need to do some reading to find out what the change was (something with the drvfs mount type?) and how to make it permanent.

  9. Vince

    Okay, it was easier than I thought.
    The solution that worked for me was to add a very simple /etc/wsl.conf:

    enabled = true
    options = "metadata"

    I found part of the answer at Stack Exchange's Super User site:

    ... but that answer resulted in fixed directory permissions and ignored file permissions for me.

    I read the referenced MS page:

    ... but using that code resulted in not mounting the host drives at all. Using just the enabled and options parts from the page resulted in fixed directory and file permissions, which kinda works, but I'd rather set the permissions myself.

    Then I remembered that the temporary solution from here only sets the "metadata" option. So, that's what I did, and it works like a charm... Just like I have a real operating system with a real filesystem.

  10. Florian Brinkmann

    @Andrew, Entitiy Black and Vince: thanks for your additional comments! I will add an additional update box to the beginning of the post pointing to the comments section with your tips 🙂



Leave a Comment

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