Please Pick an Installation Folder Other than "C:\Program Files\OpenSSH"

[DarwinJS]

The new installation instructions call for putting OpenSSH in "C:\Program Files\OpenSSH"

An internet search reveals that over time, many other versions of OpenSSH for Windows have used that as their folder.

For manual installations a user might know why a previous version is in that location and whether it is the same code as the Win32-OpenSSH project.

I would like to suggest a different folder name be used to avoid some possibly nasty issues

• overwriting a copy of OpenSSH that is not the same product (including when OpenSSH was installed as a runtime dependency by another installer - interactive users may recall installing the dependent software - but not the depedency and thereby overwrite something they need). This challenge is even more difficult with fully automated installs that must do more investigation and then have a default action (overwrite or stand down).
• other installers overwriting or updating Win32-OpenSSH when it is placed in this folder first
• dependent installers / software that wish to integrate with openssh assuming which of the other OpenSSHs distributions might be in the folder based on folder name alone. Especially while the software is in Beta and not fully functional. (yes, there fault, but still messes up users).
• without a unique programs file folder name the user will have to pick another folder in certain circumstances (whether automated install or manual). The installer should be capable of remembering this previous folder for future automated updates. This need is avoided (or at least delayed) if a unique Program Files subfolder is chosen.

[DarwinJS]

Could someone please comment on this - I am updating the chocolatey package and I'm not really interested in getting a bunch of bug reports on how the package overwrites an existing openssh client because the Program Files folder chosen by this project is in use by many other products and tools for many years now.

I also wanted to add to the above list that if the folder for the project is unique - there is no refactoring for install scripts that uses the exe folder of sshd.exe to identify whether the running version of sshd belongs to the Win32-OpenSSH project. If this folder is not unique, then I would need proper, unique EXE headers to identify that a given running sshd.exe is the one belonging to this project and I'd need to refactor install scripts.

[SteveL-MSFT]

Eventually, the expectation is that we won't have our win32-openssh fork and it's just part of openssh portable so calling it win32-openssh doesn't make sense. What do you propose we name the folder?

[DarwinJS]

I think what will end up causing the least pain for [a] the customer, [b] the installation developer and [c] the product development team, in the long run will make the most sense. Basically whatever avoids clashes with existing software in the ecosystem. The pain and headache of trying to identify if whatever is in %ProgramFiles%\openssh is a previous version yours (or something else) during upgrade or not and what to do if not.

Or if after win32-openssh gets installed there another installer overwrites files there without bothering to check whose binaries are there - the next time your installer runs it is trying to deal with a confusing situation because the evidence of your previous version is there in meta data - like an MSI product code or Uninstall entry - but isn't accurate to the binaries on the system because another software's installer has overwritten. Personally I feel this could create both a mountain of install code as well as frustration with the product.

Something that seems like a simple installer decision could bubble up to be a major product satisfaction issue.

I am not clearly seeing how the fact that you will eventually merge with portable openssh affects the install folder decision?

Also how does the merge into openssh portable affect creating an MSI installer? Does the MSI installer still get used after the merge? Is there an openssh portable installer? (The openssh portable manual install instructions are horrendous: http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/INSTALL)

Also related - I feel at least the server portions of the package should always be put into some sub folder of Program Files and this should be encouraged by being a default - that is not super easy to change - even if people are given a choice. There are a lot of extra protections for software that resides there.

Also, users can easily choose locations they don't know are writable by everyone (like ProgramData) - opening the binaries to malware. I'm not sure if openssh portable speaks to the security of the files of the server portion of the software - but I think the defaults for the Windows version should reflect good security practice as per standard DevOps and SecOps practices as known at this time.

[SteveL-MSFT]

I completely understand the name collision/squatting problem. Looking for some suggestions.

The only reason I brought up the merge is that it's known as OpenSSH. I don't want to call it Win32-OpenSSH after merging as it implies something different from OpenSSH (which it is today as a fork). Need to think about this some more.

[megamorf]

Does it necessarily have to be short? Why not WindowsOpenSSH just like WindowsPowerShell under %ProgramFiles%?

[SteveL-MSFT]

It doesn't have to be short. The %programfiles%\WindowsPowerShell folder is only used to hold modules for Windows PowerShell. PowerShell Core installs to %programfiles%\PowerShell as it's no longer just for Windows. @joeyaiello thoughts?

[DarwinJS]

I think "Windows" is better than anything with "Microsoft" in it when working with open source like this.

I'm probably stating the obvious, but "Win32" should not be used because although it is meant to distinguish "Windows binaries" versus other platform binaries - it also implies 32-bit.

What about C:\windows\System32\OpenSSH or C:\windows\System32\WindowsOpenSSH? I'm not sure what the internal Microsoft rules are about that - but SSH definitely intends to be as integrated as other terminal utilities right?

Would definitely disambiguate which version was being used by folder name alone.

[maertendMSFT]

This is by design