Win32-OpenSSH
Win32-OpenSSH copied to clipboard
Document administrators_authorized_keys file permission requirements
"OpenSSH for Windows" version: 8.1.0.1 Server OperatingSystem: Windows 11 Pro, 21H2 build 22000.675
The documentation at docs.microsoft.com refers to the administrators_authorized_keys file being used by sshd to authenticate user accounts that are members of the administrator group.
However, creating this file with proper public keys is not enough as it will inherit read permissions that must be removed before the file is accepted by sshd.
Plenty of people have been struggling with this, see fx https://stackoverflow.com/a/64868357/936466
I suggest improving the documentation at docs.microsoft.com.
An even better alternative would be to drop the administrators_authorized_keys concept entirely (discussed in #1324).
refs #1701
Also, I suggest to add some info in https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH (main installation intruction) about this: if you are going to log in via administrator account, this default sshd_config rule
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
will tell the system that your authorized keys are in ProgramData\ssh\administrators_authorized_keys, not in the users\username\.ssh\authorized_keys, as described in many articles and is more commonly used 'default' place (in my opinion). So either place your authorized keys is ProgramData\ssh\administrators_authorized_keys, or comment\remove this rule from your sshd_config (or sshd_config_default for future installations also). I had pretty the same confusing scenario as #1701. This page https://github.com/PowerShell/Win32-OpenSSH/wiki/Setup-public-key-based-authentication-for-windows is:
- not metnioned in main instruction which is probably main "info-path" of configuration process;
- it is even undiscoverable on the wiki - https://github.com/PowerShell/Win32-OpenSSH/wiki, at least I haven't find the article's title on this page; (How can I find this article other than in direct issue reply?)
- still even that artcile looks kinda overwhelmingly difficult for the first run of ssh, and probably basic instruction should contain simpler configuration too.
Ps. I would really just comment that group administator rule in the config, as #1701 said it is hardly possible whilst debugging even with highest degree of detail to trace to the fact, that system expects another authorized keys filename because of its config, as you just see in the console debug log that server just ignore correct client pub key sending and goes to the next auth method (if exists), whilst having at the same time "correct" (in not that experienced user's mind) authorized_keys file that passes all fix checks of internal fix checker. At the same time config file might look at glance quite long, feature-rich, application-important and like a part of the whole project's internal source codebase (as it really is in some sense), which may not look like the thing to trick firstly if ever.
In my opinion, to login with the administrators admin privilege should not be a default option. Naturally, it looks like an optional feature for who needs the admin privilege.
In my opinion, to login with the administrators admin privilege should not be a default option. Naturally, it looks like an optional feature for who needs the admin privilege.
Logging in as an administrator can be useful for SSHing into a desktop computer on a local network where security is less of an issue and we are just the owner of the computer, trying to access our other computer via a laptop.
Otherwise, one needs to create an entirely new user, just for the purposes of SSHing into the machine, making the process of SSHing into our own machines more difficult than something like this should be.
The fact that it is necessary to fiddle with C:\ProgramData\ssh\sshd_config to comment these two lines"
#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
is a significant PITA for anyone who is setting up Windows Server virtual machine and want to streamline operations against the VM. For such environments security is not a concern at all e.g. used for testing and development; setting up Kubernetes with Windows nodes for testing (think Kubernetes SIG-Windows). Such use cases are important.