I have Windows 10 with Git installed. This Git uses my C:/Users/MyName dir as the HOME directory and the /.ssh/ dir within, appropriately for sourcing my private SSH keys.

I have just enabled and setup "Bash on Ubuntu on Windows" (what a mouthful!) and installed Git therein also. I would like both Gits to use the same set of keys such that it does not matter what environment I work in on this machine, my commits will always come from me.

Trouble being that the HOME dir in bash is different (/home/MyName) and thus it does not see the keys located in the now distant ../../mnt/c/Users/MyName/.ssh. I thought I'd be on to a winner by changing the HOME environment variable using

export HOME=/c/mnt/Users/MyName

This did change the HOME dir successfully but the bash git still does not see the keys contained within the ./.ssh dir.

I'm not sure if this is A) because bash git expects keys in a different file format? (current ones are id_rsa and id_rsa.pub) B) bash git is ignoring the changed HOME variable? Or maybe both.

I'm also not sure C) if arbitrarily changing the HOME variable like this is a good idea in general w.r.t other programs that might reference it?

  • 2
    Sounds like it's time for a symlink.
    – Telastyn
    Commented Aug 9, 2016 at 14:41
  • Hmm .sshalready exists at /home/MyName... can one symlink files? such that I would do ln -s /mnt/c/Users/MyName/.ssh/id_rsa /.ssh/id_rsa? (new to symlinking too!)
    – Toby
    Commented Aug 9, 2016 at 14:50
  • BOOM! That works a treat! @Telastyn if you'd like to make your comment into an answer I'll accept :-) (Though I'm still unsure why just changing the HOME var didn't work in the first place)
    – Toby
    Commented Aug 9, 2016 at 14:54
  • 2
    It works better if you symlink the whole .ssh directory.
    – tripleee
    Commented Nov 11, 2016 at 5:12
  • 1
    My recollection is that PuTTY puts its stuff in altogether some different location but it's been over a year since I last had to touch Windows (thank $dmr)
    – tripleee
    Commented Nov 11, 2016 at 10:23

2 Answers 2


So as Telastyn commented I added symlinks in WSLs ~/.ssh/ to the id_rsa and id_rsa.pub using:

> ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa
> ln -s /mnt/c/Users/MyName/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub

Using the same technique to instead link the symlink directory as suggested by tripleee, I had issues until I saw that the trailing slashes I used in the ln command (left from using the tab key to have bash fill out the directory name) were an issue. Thus, instead of doing the above one could better do:

> ln -s /mnt/c/Users/Myname/.ssh ~/.ssh

The known_hosts file does differ slightly between my use of it (git in powershell using the ssh-agent) in Windows and the SSH use of it in WSL, whereby the host-name and IP are not hashed in the Windows version. According to the man page for ssh-config, there is a flag available to disable this hashing which I took to mean SSH would understand the file without the hashing which has worked out so far.

This latter method means that the details used for SSH used between the two different environments are exactly the same.

Thanks to Matěj Kříž for pointing out a small but vital missing character!

  • 3
    It should be > ln -s /mnt/c/Users/MyName/.ssh/id_rsa ~/.ssh/id_rsa add "~". Nope? Commented May 10, 2017 at 11:55
  • 9
    note that it is not possible to use the private keys from bash on windows if ones makes s link between the directories. Doing so will cause ssh agent to complain about bad permission on private key files. Since the files mounted from window their permission cannot be changed.
    – oak
    Commented Dec 14, 2017 at 12:27
  • @oak is it possible at all with bash?
    – Tj Gienger
    Commented May 2, 2018 at 19:02
  • @TjGienger what do you mean?
    – oak
    Commented May 3, 2018 at 19:25
  • @oak, is this perhaps what the Entity Black is trying to fix below? Or is that addressing a different issue?
    – sferencik
    Commented Jun 14, 2018 at 15:06

Based on the new build "Insider Build 17063" permissions for files works differently now. In short you need to do:

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

This will make permissions for your ssh folder work as you need. Then procced as OP suggests in his answer.

Relevant links:

https://github.com/Microsoft/WSL/issues/3181 https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/


I'm back to this question because I find out this is only temporary solution (yes I'm stupid). Each time you restart (logout) your WSL, you need to cast this commands again.

So the solution that works for me now is to edit (create) config file /etc/wsl.conf in my wsl ubuntu, and put inside following, then restart to do mounts again:

# Enable extra metadata options by default, set uid and gid to 0
options = "metadata,uid=,gid="

Why I add metadata:

Linux permissions are added as additional metadata to the file. This means a file can have Linux and Windows read/write/execute permission bits.

Why set uid and gid:

By default, WSL sets the uid and gid to the value of the default user (in Ubuntu distro, the default user is created with uid=1000,gid=1000). If the user specifies a gid or uid option explicitly via this key, the associated value will be overwritten. Otherwise, the default value will always be appended.

Relevant links:

https://docs.microsoft.com/en-us/windows/wsl/wsl-config https://blogs.msdn.microsoft.com/commandline/2018/02/07/automatically-configuring-wsl/ https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.