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.
Update from July 10, 2018: Darren mentioned in his comment, that using SSH alias with the described solution will fail, and how to solve that.
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.
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
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):
Code language: Bash (bash)
ln -s /mnt/c/Users/Florian/.ssh ~/.ssh
That creates a link from
/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.