Respect Windows file path conventions.

"OpenSSH for Windows" version
7.7.2.1

Server OperatingSystem
N/A

Client OperatingSystem
Windows 10 Pro

What is failing
SSH is reading configuration files from the wrong location.

In Linux, $HOME / ~ / /home/<user> is a dumping ground for user personal files, application configuration files, cache files, downloads, etc. In Windows, there are specific directories for each of these things. In particular, %USERPROFILE% is the root location for a bunch of other paths but should never be used for writing anything directly to unless the user explicitly chooses to do so via a save dialog or other user input.

For configuration files, like SSH config, the proper location on Windows is %APPDATA%/ssh. This is well documented in Microsoft's OS developer documentation and generally respected by most Windows applications, with the unfortunate exception being apps ported from Linux by people not familiar with Windows conventions (usually due to no fault of their own, they usually just lack the knowledge of Windows conventions).

Unfortunately, since OpenSSH on Windows has already launched, changing this behavior will require a migration strategy. Given that OpenSSH is written in C (not a particularly friendly language for doing migrations in), and since this is a security critical piece of software a reasonable temporary compromise would be the introduction of an environment variable like SSH_CONFIG_PATH.

An ideal solution would be a migration path that would first try to read config from passed in CLI parameter, then fallback to %APPDATA%/ssh/config and then fallback to reading from %USERPROFILE%/.ssh/config. If a file is found in %USERPROFILE/.ssh/config then it would be copied to %APPDATA%/ssh/config on read.

It is worth figuring out how to deal with compatibility with other applications that are expecting %USERPROFILE%/.ssh/config to exist. These applications should also be updated to support proper Windows folder structures, but that isn't something we can force here and making things "just work" is valuable.

Another option is on startup to move the entire contents of %USERPROFILE%/.ssh/ to %APPDATA%/ssh/ if it exists and afterwards create a symlink at %USERPROFILE%/.ssh pointing at %APPDATA%/ssh. The user can then, at their leisure, delete the symlink if desired. If they have other applications that expect config in %USERPROFILE%/.ssh it is easy enough to not delete or recreate the symlink, and users who don't have any applications violating Windows conventions can simply delete the symlink after the first run of a new version of OpenSSH.

Looking over the code, it appears the current behavior is to hard code /home on Linux and C:\Users\ on Windows and otherwise treat them the same throughout the codebase. While I can appreciate the desire to have this project closely mirror the Linux project, it is incorrect to say that C:\Users is the Windows equivalent of /home. There is really no great analog on Windows, and so the maintainers of this project must choose a location for the files in question that is most appropriate, and that is definitely not %USERPROFILE%

Related Issue

#1146 is somewhat related and there was a discussion on this topic that appears to have gotten lost, but the issue creator was wanting OpenSSH to read from $HOME, which I can appreciate not being proper Windows behavior.

Start by tracing the code paths that hard-code /home and C:\Users for SSH configuration files. Review the related discussion in issue #1146 before choosing between an environment-variable override, migration to %APPDATA%/ssh, or a compatibility symlink; done requires an agreed migration strategy and verified Windows behavior.