The Bonus OpenSSH – Or Not?

Previously, I connected into the OpenSSH server that became active by default if you activated Developer Mode in Windows 10 and were running a recent enough version.  This, however, connects into a standard Windows cmd shell which is not what I was hoping for.  So, with a goal of connecting to the WSL Bash command line there are a couple of different routes that immediately come to mind.

One route is to attempt an install of openssh-server in the WSL.  The method for this is pretty straightforward.  Root shell and apt-get install openssh-server.  Install starts out with no surprises, packages pulled down, unpacked, keys created.  Right until it attempted to have Upstart kick things off.  That is when we hit the wall.  The relevant error messages spit out during the installation were:

initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused

runlevel:/var/run/utmp: No such file or directory

invoke-rc.d: policy-rc.d denied execution of restart.

So the services needed to get this executing are not running and are not being started on demand.  This can be further verified by doing a process list, where the only background process running is init, and this init is kicked off with the command /init, not /sbin/init as would be normally expected.  Furthermore, /sbin/init does exist (along with many of the other files that would be expected in /sbin) but it is different than the one running.  Is this because the system calls needed to handle this are not yet implemented?

In a series of videos explaining the WSL (Windows Subsystem for Linux) architecture here:

https://blogs.msdn.microsoft.com/commandline/2016/06/02/learn-more-about-bash-on-ubuntu-on-windows-and-the-windows-subsystem-for-linux/

they talk generally about how Linux processes work with the NT kernel and how support has been implemented.  Which is basically that they have a driver in the kernel that handles Linux system calls.  So, there are two items of note relating to this.  1) In the video on architectural overview, Deepu Thomas mentions that sshd requires a good pseudo terminal implementation, which is not yet done. (Although this particular video was recorded back in April, so you can always hope they have made further progress.)  2) In the video on WSL system calls, Stephen Hufnagel does an estimate of their progress on Linux system call implementations.  He says that out of approximately 300 system calls, they have implemented somewhere in excess of 150.  The rest they are still working on.  So, have they yet implemented the ones required for the particular services we are interested in?  I guess I’ll circle back to that.

Another route to getting a Bash shell via ssh is to go through the existing openssh server.  Since you can run bash.exe from the cmd command line and ssh’ing in drops you into a cmd command line, can you jump to Bash from there?  Attempting to execute bash.exe after connecting with ssh spits out the message:  Error: 0x80070020.  Attempting it again at a different time:  Error: 0x80070005.  Either way, no dice.  A little more investigation leads to a comment in a bug report and a surprise (to me):

Closing this issue for now since, as mentioned above, this SSH server is only a minimal SSH server used for device discovery scenarios and it doesn't support all the high-fidelity SSH features one would expect or rely upon.

If you want to run an OpenSSH Server on Windows, know that the real OpenSSH is currently being ported to support Windows as we type: https://github.com/PowerShell/Win32-OpenSSH

Link bug report: https://github.com/Microsoft/BashOnWindows/issues/777

So, maybe our bonus OpenSSH server is not the bonus previously assumed.  Connecting in via ssh and using the –v flag to get version information (among other things), reveals that the reported version of the default ssh server enabled with the Developer Mode turned on in Windows 10 is “Remote protocol version 2.0, remote software version MS_1.100”.  Huh.  The version reported by an ssh server running on XUbuntu 14.04 gives “Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8”.  So, delving into the above GitHub project - releases, wiki and installation instructions - it would appear that the default ssh server is not that one.  Evidently, not quite the assumed bonus.  And we all know what happens when you assume.