git GNU/Linux ssh Windows

Dealing with SSH key management in a mixed Windows and GNU/Linux environment with WSL.

I am going to drop a bunch of tips which may be useful to people using SSH in a extensive way for development to authenticate against their remote git user in say Gitlab, Gitea, Github or Bitbucket and happens to not being able to work in the best operative system for development.

The first thing is SSH key generation, you surely would not like to have to update your SSH key in the remote Git server because you accidentally generated a new pair of keys so you should be careful while typing the ssh-keygen, you should do it before submiting your key to the remote server and NEVER again.

Choose carefully the root of your ssh keys in every computer and put yourself the rule of never overriding that SSH key pair to avoid losing accidentally the access to the remote repository.

That said you install your GNU/Linux distribution of choice, generate a key pair and submit the .ssh/ to the remote repository and then you should be able to work from your WSL user cloning repositories, but then you want to clone the repository in for example a directory owned by www-data.

You may try:

cd /var/www/
sudo git clone ssh://user@host/myfancyrepo

That will give you a beautiful permission denied and you may stick confused because of this, but you should be aware ssh keys are private for every user, so if you think about it, it’s simply logic root has different ssh keys than your user.

A correct approach would be:

sudo mkdir ~root/.ssh
sudo cp ~/.ssh/id_rsa{,.pub} ~root/.ssh
sudo git clone ssh://user@host/myfancyrepo

But correct is not good, a better approach would be to do it with the user owner of the folder like this since when the directory with the repository is created if it needs some sort of installation, say composer or npm you will be tempted to do that installation with root which is absolutely discouraged.

sudo mkdir ~www-data/.ssh
sudo cp ~/.ssh/id_rsa{,.pub} ~www-data/.ssh/
sudo -u www-data git clone ssh://user@host/myfancyrepo

If you are too often having to use git repositories outside your WSL environment in Windows folders, you will find soon how slow it can get, I recommend you to install the Git for Windows and ensure it is in the Windows PATH and then add this lines to your .bashrc:

export WIN_DIR=/mnt/c
export GIT=$(which git)

git_wrapper() {
    if perl -e 'exit int($ARGV[1] !~ /^@{[$ARGV[0]]}(?:\/|$)/)' $WIN_DIR $PWD; then
        git.exe $@ 
        $GIT $@

alias git=git_wrapper 

You will need to copy your SSH keys to the Windows user like this:

sudo mkdir -pv /mnt/c/Users/<youruser>/.ssh/
sudo cp ~/.ssh/{id_rsa{,.pub} /mnt/c/Users/<youruser>/.ssh/

This should allow you to painlessly be able to use wsl to work with both WSL repositories and Windows ones.

This post is a compilation of common issues I have been seen and suffered during the development in Windows in my job and I hope it helps somebody else to do not fall in some traps to the newbies leading with SSH key management.


Will we see any time soon the end of Windows in corporative environments?

I hope so, just other 2021 will be the year of the GNU/Linux desktop post.

As everybody knows Windows has been dominating the operative system desktop market for decades, but there is a live outside it and a lot of reputable tech people thinks it is time it ends.

Here I will drop some hints to understand that thought and to encourage enterprises to start upgrading user stations to the operative system of the future, GNU/Linux because the great advantages it has been giving over its legacy alternative Windows in a race of more than 20 years taking way better decisions for mantaintanibility and security.

The first is reason is just the common usage of users of Windows is a security nightmare with default execution permission for downloaded files is just to easy to be tricked to infect you, there is no need to escalate your privileges to Administrator since the most important information a user manages like passwords and sensible documents is just accesible from the privileges a common user has.

The second reason is Windows mades more difficult to users to automatize proccess with lite knowledge, the tools Windows gives without installing things, VBS, Powershell and CMD have greater learning curves and are less diverse than the GNU/Linux alternatives, Perl, Python, Bash, AWK, Sed, WSL makes something to solve it at the prize of not having good/easy integration with the Windows programs and requires installation of course.

The third reason is webapps, since they are easier and cheaper to program almost everything is moving to the web, if all the software a employee uses can be used from the web,. What do the OS matter? Why to pay licenses?

The fourth reason is support, as the time passes more and more tech persons use mostly GNU/Linux, finding IT support for your Windows environments can become more expensive since they are harder to administer and tech persons are starting to less contact with it. So it can be the time to migrate before Windows start being your own Cobol and you have to go to TV to pray for help to find someone to support you.

Relative to this migrating from a version of Windows to other is very difficult and expensive, the distro of your choice and continuous Ansible scripts to update after testing the new update and adapting the code makes the migration to new versions a continuous but less disruptive process.

I hope you find this post useful and you think about stepping out of Windows in your bussiness.