Troubleshooting Windows Subsystem for Linux and SSH

The Windows Subsystem for Linux (WSL) is one of the best features on Windows 10. It makes development so much easier than it used to be but still has a few hiccups. Kinda like Linux, some things don’t “just work.” One pesky thing that I recently dealt with was getting SSH to work with a keypair file from WSL. Here is how to get SSH working on WSL.

Goal

Given a keypair file, we want to invoke ssh from the command line and establish a tunnel to another server. This is a common task when connecting to remote servers. Think AWS, Azure, or Digital Ocean. It is a simple command:

$ ssh -i /path/to/keypair.pem

But WSL may throw a permissions error similar to:

Why?

Windows and Linux manage file permissions in a different way. For a detailed look at interoperability between a Windows and Linux filesystem see this blog post. Some excerpts are included below.

File systems on Windows

https://docs.microsoft.com/en-us/archive/blogs/wsl/wsl-file-system-support

File systems on Linux

https://docs.microsoft.com/en-us/archive/blogs/wsl/wsl-file-system-support

One of the many things that is handled differently is how file permissions are handled. Linux flips bits to set the various file permissions. For a detailed explanation read the chmod man page or the excellent blog post by Nitin V.

Table of Linux File Permissions – https://nitstorm.github.io/blog/understanding-linux-file-permissions/

Windows stores files as objects. The Windows file system manager provides a general interface for dealing with file objects and leaves fine grained operations to the file system drivers. One of the ways users bump into those differences is through file permissions. WSL, in trying to provide a level of interoperability attempts to support working on files across both systems through a single interface.

WSL Virtual File System – https://docs.microsoft.com/en-us/archive/blogs/wsl/wsl-file-system-support#file-systems-in-wsl

This is cool, complex, and has unintended side effects. One being, SSH can run into file permission problems if the host drive is mounted without file permissions exposed in a Linux friendly format. There are two ways to fix it. Place the .pem file in the WSL home directory (cd ~). Once it is there, you should be able to run $ chmod 600 keyfile.pem and create an SSH session. The other, more complicated way, is to remount the drive with metadata enabled. You will need to unmount the drive, remount it with DrvFs, and verify that the additional metadata is enabled. To do that run:

Confirm that metadata is enabled and you should be able to chown the keypair file and initiate an SSH session. WSL is being improved constantly and has become much better over the past couple years. I use it everyday at work and home. Its functionality has me working more in the Windows environment despite my home machine’s dual boot capabilities.