Windows Subsystem For Linux – Part 1 – Remote Stuff

While all PCs and notebooks I personally own run on Linux, I can still not totally escape Windows on other machines. Apart from not being FOSS, the other thing that bothers me when I have to use or support a Windows machine is that the tools and programs for local and remote maintenance and backup are entirely different. But perhaps there is hope now… In 2016, Microsoft announced what is now known as the ‘Windows Subsystem for Linux‘ or WSL for short, which emulates a Linux kernel API so Linux binaries can run on Windows as well. Kind of a reverse-Wine. So how well does this work and could I use this to remotely administer Windows boxes in the same way as Linux boxes?

I recently tried out WSL to see how far I would get in terms of using the same tools for remote administration as I would for a Linux box and if I could get some graphical Linux programs running on the Windows machine that have no adequate local equivalent. Here’s my result:

Installing the Windows Subsystem for Linux (WSL) is quite straight forward. After activation and reboot one can download an Ubuntu 16.04, 18.04 or other Linux distribution from the Microsoft store. It takes a few minutes to download and install and once done, one can open a bash shell on Windows and things are up and running. The first thing to do then is an ‘apt update && apt upgrade‘ to get the latest updates and to configure a few things that are not part of the Ubuntu image download.

The SSH Server

To securely administer things remotely, I used SSH as my swiss knife and secure transport channel. The first thing I need SSH for is to get a remote shell in which I can use well known Linux command line tools. Like on a real Linux system, the SSH server is installed with an ‘apt install‘ command. Configuration files are where they are supposed to be in ‘/etc/ssh‘. The only thing that has to be configured specifically on the Windows side is the Windows firewall, as by default, it blocks incoming connections to TCP ports. Once that is done, the SSH server is accessible from the outside.

Tunneling the SSH Server Port to Another Machine

In most cases the devices I administer are behind NATs and other nasty network equipment that prevent direct access to the machine. The solution is to use the SSH client software on the remote machine to export the TCP port used by the SSH server over the Internet to a machine in my network. On WSL this workes just as well as it does on a real Linux machine. Nice! In addition to this I use a script that is invoked via crontab every 5 minutes to check if the TCP port tunnel is still up and if not, tries to reestablish it. This requires the cron service which is not started by default in WSL. So I use a ‘sudo service cron start‘ command in .bashrc and a Windows batch file in the Windows autostart folder to open a bash shell when the user first logs in.  A crude hack but it works. I do the same for the ‘rsyslog’ daemon so it generates log files in /var/log/syslog in WSL. The ssh daemon is started in a similar way. Once the daemons are started, they keep working in the background even if the bash windows are closed.

Remote RSYNC

Another important thing I do over the Internet is to backup remote machines with ‘rsync‘. This requires rsync and sshd on the remote WSL machine and access to the files of the user(s) from the Linux environment. Again, this works nicely as well, as Windows volumes are reachable for Linux programs via ‘/mnt/…‘. A special WSL file system driver is used for this so Linux programs don’t see the partitions as NTFS drives. Very nice!

Remote Screen and Keyboard

Yes, there are services like Teamviewer for exporting the screen over the Internet but I rather like something more FOSS and private. In the past I used TightVNC on Windows for the purpose and it still works very nicely on Windows 10 as well. In the TightVNC Server settings I’ve allowed the use over ‘loopback’ and specifically limited access to TightVNC to the loopback device. I then use ssh to export port 5900 to a machine in my own network. This way I can securely access the screen of the remote machine over an encrypted SSH tunnel while the TCP port used for screen export is not even available in the local network of the device. Works as expected and the screenshot at the beginning of the post shows a wild mix of Ubuntu, Windows 10, WSL, TightVNC, Remina, Bash, htop and Word. You figure out what runs on what.

Summary

I’m impressed, Windows Subsystem For Linux allows me to remotely access, administer and support Windows machines in exactly the same way as I would a remote Linux box. Screen sharing works and even backing up the computer over rsync works out of the box.

So much for today. In a follow up post I will have a look at how to use graphical Linux programs on a Windows box for which there is no reasonable native alternative.