Why did you choose the service name "sshd"...

[github-cygwin]

...even though Cygwin OpenSSH was using it for the last 16 or 17 years?

As OS creator you can do as you like, but I'm curious why you didn't even bother to do the polite thing to contact us @ Cygwin. This is pretty disappointing.

Corinna

[manojampalam]

Sincere apologies. We were not aware of the conflict in the first place, nor prudent enough to check how Cygwin is hosting OpenSSH.

I'll put the following notes in wiki:
Note to Cygwin users, to host Cygwin's version of OpenSSH daemon, you need to first delete Win32 OpenSSH service registration
sc.exe delete sshd

You may host Cygwin's OpenSSH daemon along side Win32's version by registering the later with a different name (say win32sshd), by doing the following in elevated Powershell
New-Service -Name win32sshd -BinaryPathName 'C:\Program Files\OpenSSH\sshd.exe' -StartupType Manual

[github-cygwin]

Accepted. However, I sent a patch upstream a couple of minutes ago which changes the Cygwin sshd installer script to use the service name "cygsshd" by default in future. I expect this will go into upstream OpenSSH 8.0.

You may want to tweak your Wiki entry to mention this problem specificially for existing Cygwin installations.

One other point though:

A Windows update actually removes an existing Cygwin sshd installation and replaces it with Win32 OpenSSH. This is extremly disruptive and very certainly not what the user wants.

On a test installation I was unable to login with pubkey auth and it took me quite some time to realize I'm running the wrong service!

So please change your update procedure to install the sshd service only if it doesn't already exist.

Thanks,
Corinna

[github-cygwin]

Btw., how big is the chance that you rename your service rather than that we have to step aside?
Something like "w32sshd" would work for you, too.

Corinna

[DarwinJS]

Hello - I am the Chocolatey packager for openssh. I have been doing some advocacy for not clashing with existing solutions in this space. In fact, the chocolatey package always confirms if the service called sshd is the Microsoft one before proceeding.

While I have been an advocate, since openssh has lacked a regular installer, I'm sure there are a lot of installers and config MGMT systems that expect that specific name.

My efforts to advocate in this area helped inform the decision not to "enable by default" the Microsoft sshd solution after a given patch level of Windows.

And even though I do advocate for avoiding clashes for existing solutions I do feel that a native version of something should be allowed to utilize the defacto service name / binary name.

IMO the effort to avoid clashes at this level would be in installer code that does not assume the service name belongs exclusively to a given vendor.

For instance Microsoft now has native tar and curl binaries and they call them "tar" and "curl".

This approach to avoiding unnecessary customer disruptions by all solutions
implies all sshd installers from all sshd solutons should:

• check for existence and vendor ownership of sshd before installing - exit with a message and suppressable error code indicating why install / upgrade can't happen
• same for upgrades
• same for uninstalls
• all of the above operations should check if sshd belongs to themselves EVERY time - e.g. don't assume sshd is yours just because your uninstaller is on the system (something may have changed it to another vendors solution)

The Chocolatey package is designed to act like the above - if you find it lacking in respecting the existence of cygwin sshd please drop me an issue at https://github.com/darwinjs/chocopackages/issues

Fyi the Chocolatey package is not used by Windows Feature On Demand (OS optional features) distribution channel. Also, I am a volunteer on the project and cannot speak to the decisions or requirements that Microsoft Feature On Demand works under.