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.

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.

Supposed solution

The first problem: 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/.

After a bit of searching, I found a Stack Exchange response with the supposedly simple solution to create a symlink, so that ~/.ssh/ points to C:/Users/Username/.ssh/. Said and done. After that, I generated a key and tested it. The result was an error — the permissions of the private key are too open, so the ssh command ignores it. I failed with changing the permissions because the subsystem cannot modify permissions inside C and also the Windows command line brought no success.

Working solution

Now the solution that works for me. Because of the permission problems, the key has to exist twice — in ~/.ssh/ and /mnt/c/Users/Florian/.ssh/. So let us create a new key from the subsystem first with the following command (I ran bash as admin, but that may not be necessary):

ssh-keygen -t rsa -b 4096

We press Enter when the bash asks us to provide a directory, so we use the default directory and name. After that, we choose a passphrase and are done with key creation.

Now let us copy the private and public key into the SSH directory of Windows:

cp ~/.ssh/. -R /mnt/c/Users/Florian/.ssh/

If we now connect to a server for the first time, we will get the server’s fingerprint to check if it is the correct one. After confirming that, a known_hosts file in the SSH directory will be either created or updated, so we are not asked to confirm the connection with this server again because it is a known host.

But if you, for example, connect to a server via git shell on Windows, and after that via the subsystem, you need to confirm the connection twice, because there are two different known_hosts files. To prevent that, we create a symlink from ~/.ssh/known_hosts to /mnt/c/Users/Florian/.ssh/known_hosts, so the Linux subsystem uses the known_hosts file from the Windows directory.

To make it happen, just run that command:

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

And that is it. Not the most beautiful solution, because the key files exist twice, but okay. If you now a solution where the key only exists once, please write a comment! 🙂

Related posts

6 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

Leave a Comment

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