sshd issues on Windows 10 version 1803

Hiya Z
Fri Jun 22 20:42:00 GMT 2018


Now that Microsoft has bundled OpenSSH for Windows in update 1803 (see,
here are some observations and the resulting unfortunate behavior:

-  On a clean vanilla 1803 install, even with Windows Subsystem for Linux
(WSL) not installed, there exists a folder %SystemRoot%\system32\openssh
that has native Windows ssh and sshd executables.

-  %SystemRoot%\system32\openssh is added to the system PATH.

-  a (manual start) service "sshd", displayname="OpenSSH SSH Server",
imagepath=%SystemRoot%\system32\openssh\sshd.exe, gets created.

All of the above have the unfortunate consequence that Cygwin sshd no
longer works reliably on a 1803 install. First, the service name "sshd"
conflicts. This can be worked around by something like "ssh-host-config -N
cygwinsshd". Even then, the Cygwin sshd does not always automatically start
upon reboot. The Windows sshd is not configured/running, so there should
not be a port conflict. SCM reports timeouts (waiting for cygwinsshd to
respond) in the event viewer. A manual "sc start cygwinsshd" works, but
again, upon the next reboot, the problem is back.

There are other permutations depending on the sequence of install. If I
were to upgrade a Windows 10 1709 node with a working Cygwin sshd, it seems
that the 1803 update detects an existing sshd registry key (which really is
Cygwin), does not clobber the registry keys, nor does it install sshd.exe
under %SystemRoot%\system32\openssh (though ssh.exe and family get
installed). Even on this node, the Cygwin sshd shows the same issue of not
autostarting reliably upon reboots.

I am not sure what Cygwin can do... but reporting this issue to see if
Cygwin sshd can be fixed to autostart reliably upon reboots. As a minimum,
the default service name in ssh-host-config should be changed to not
collide with Windows "sshd".


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list