The purpose of this post is to detail how to setup Git within the Windows Subsystem for Linux (WSL). Git is the source control tool of choice nowadays. It’s distributed style makes it great for working with a remote team but also allows you to work completely offline, which wasn’t an option for previous tools like Subversion or CVS.

This post focuses on setting up Git for command line access and scripting on Windows. There are other options like Git BASH, which I have used in the past, but why settle for a “BASH emulation” when you can use the real thing?

Install Git

Git appears to come as standard as part of the WSL install. You can test this by running:

$ git --version
git version 2.17.1

If for some reason Git is not installed then you can simply pull it down:

$ sudo apt install git

Setup global configuration settings

First up you need to configure your name and email address, e.g:

$ git config --global "Pete O'Shea"
$ git config --global ""

This is used to mark you as the author of the changes you make. I also recommend turning off the auto line endings feature as this can hide certain issues especially when working with both Linux and Windows. There is another config setting to achieve this:

$ git config --global core.autocrlf false

If you prefer you can just edit the global config for the current user directly:

$ git config --global --edit

This does use the default editor, which seems to default to Nano. If you’ve never used Nano before you may prefer to just edit the file directly with something like Vi:

$ vi ~/.gitconfig

Anyway this file should look something like:

# This is Git's per-user configuration file.
        name = Pete O'Shea
        email = ""

        autocrlf = false

Checking configuration settings

If you want to check your settings you can run:

$ git config --list --show-origin
file:/home/pete/.gitconfig O'Shea
file:/home/pete/.gitconfig      core.autocrlf=false

This shows you the settings and the value they have been set to. It also shows which configuration file the values come from so if you run this within a git repository for example there may be some extra project specific settings included.

Sharing an existing SSH key between Windows and WSL

If you have an SSH key already setup on Windows you could reuse it rather than creating a new one. (Note that PuTTY keys do not work here). To do this you can just copy the key from the Windows filesystem into the WSL’s filesystem. Linux has some rules about how visible the key is. So you need to make sure the access levels are strict enough to meet these requirements:

$ cd ~
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ cp /mnt/c/Users/user/.ssh/id_rsa* .
$ chmod 600 id_rsa
$ chmod 644

Creating a new SSH key

If you do not already have an SSH key then you could generate one in WSL:

$ ssh-keygen -t rsa -b 4096 -C ""

Save the key as id_rsa in the .ssh directory in your home directory, e.g. /home/pete/.ssh/id_rsa for user pete.

As mentioned earlier you will likely want to copy this file back to the Windows system. A good reason for this is that the WSL distro could be uninstalled or a second system could be setup and you don’t want to lose your key or have to setup a new key for each environment on the same machine.

$ cd /mnt/c/Users/user
$ ls -la

If .ssh isn’t listed then create it now:

$ mkdir .ssh

Now you can copy these files so that Windows and WSL can use the same key:

$ cd .ssh
$ cp ~/.ssh/id_rsa* .

This gives you the additional benefit that you have a copy of the key on the main Windows filesystem. This is very useful if you remove the specific WSL Linux distribution app, or want to use multiple distros.

One additional step here though might be to set the id_rsa file to be read-only in Windows. Using chmod from WSL doesn’t seem to work so you’ll have to do this in Windows Explorer.

Your public key

To make use of your key the public key needs to be added to remote systems. This will then allow secure connections using your private key. The details of the public key can be retrieved with:

$ cat ~/.ssh/

Add this public SSH key to the services you use e.g. GitHub and Bitbucket. You may also want to add it to the authorized_keys file on remote servers to allow SSH access using the key.




Thank you, this was very helpful!

Francisco Eduardo Pantoja Guillén

Thanks a lot, it really helped me while working wit Git on WSl for Windows. I think you didn´t cover an important topic here, You didn´t talk about how to add the SSH key to the ssh-agent. Sorry for my English

    Pete O'Shea

    I haven’t actually had a need to use the ssh-agent yet. As long as the SSH key is in the standard place, e.g. `~/.ssh/id_rsa`, then it just picks it up and works. I didn’t use a passphrase much in the past but now that I have started using a passphrase on my keys I am starting to think it may be worth looking into the ssh-agent to save me having to enter the passphrase on every command. I tend to use a GUI tool for most of my Git work though, like SourceTree, so haven’t bothered yet. Maybe a topic for a future post or an update to this one…

Ishita Singh

when I am using “sudo apt install git” command, it is givin me error:
dpkg was interrupted, you must manually run ‘sudo dpkg –configure -a’ to correct the problem.
I don’t know what to do please help.

Leave a reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.