Match Group administrators rule in sshd_config blocks public key auth

[vritme]

Since v7.9.0.0p1-Beta sshd_config_default includes this two uncommented lines (after comment with description).

'# Example of overriding settings on a per-user basis'
'#Match User anoncvs'
'# AllowTcpForwarding no'
'# PermitTTY no'
'# ForceCommand cvs server'

'Match Group administrators'
' AuthorizedKeysFile PROGRAMDATA/ssh/administrators_authorized_keys'

In my case on 2 windows 10 machines this rule was preventing public key authentication.

I discovered it accidentially, created empty config file BEFORE ssh installation and firtst start of ssh (with default config creation) in order to emulate exact intallation conditions of this article - https://www.windowstechupdates.com/solved-how-to-install-openssh-server-client-on-windows-server-2016-1607-or-before/ - I mean version of openssh and exact output of powershell - success host files fix with report about each of them !before their automatic creation at first start.
So, to do that I created empty files for each host key and config just to "fit" them into fixhostfiles repairer, to make powershell print success checks about these files.
And then I launch ssh with that empty - in fact pure defalut - config, so that this two lines were removed.
Authorized keys were configured already, so I successfully connected with public key for the first time after many tries.
On next machine while installing, I decided to keep latest version, not the one that was actual by the date of the article, just to change folder from Program Files to Windows\System32. It doesn't help, so I tried host files repairing and empty config - that again worked.
Then I returned basic config - pubic key auth again doesn't work. So I have deleted all comment lines in config, left just active, and tested them line by line: basic authorized keys path, something with sftp, and that group administators rule.
And surely find that unsuccessful public key authentication was caused by this lines.
Finally, I did installtation in Program Files, started openssh server and agent from services with new host key files generation, did no host files reparing whatsoever (since services started with no problems), used latest (not the one from the article) version, did just config file replacement (3 lines - no to password, keyboard and challenge response auth methods) - and again public auth worked. So the problem was not in folder, nor in host files security permissions, just with this default config rules.

Notes:
I've noted that if service starts and creates host files at first run by itself - it doesn't need for any repairments, since the files were created by the service itself. The only situation when I had Error 1607 - process terminated, when service doesn't start, is when I generated host key files via ssh-keygen.exe -A prior first service run - in that case FixHostFiles repairer did it's job and allow services to start after file repairing.

Also I think, it is actually better to install in Windows\System32 as the last has no problem with 'cd' command (' cd Program Files ' gives an error, only ' cd 'Program Files' ' works) and in system32 ssh looks more like a native service, also internal openssh implementation from windows since v1709 and above (through 'Add a feature') installs files in Windows\System32\OpenSSH - https://www.bleepingcomputer.com/news/microsoft/how-to-install-the-built-in-windows-10-openssh-server/.
Not critical at all, just to 'look' for the system more like a 'built-in' service).

[tgauth]

Have you looked at the wiki page for public key auth?https://github.com/PowerShell/Win32-OpenSSH/wiki/Setup-public-key-based-authentication-for-windows

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

This directive in the config file tells sshd to look for the public keys of users with administrator privileges in the PROGRAMDATA/ssh/administrators_authorized_keys file. For non-admin users, the public key would be in the $env:USERPROFILE.ssh\authorized_keys file.

If possible, can you try public key auth for both an admin user & non-admin user based on the wiki instructions and see if the issue persists?

[vritme]

This directive in the config file tells sshd to look for the public keys of users with administrator privileges in the PROGRAMDATA/ssh/administrators_authorized_keys file. For non-admin users, the public key would be in the $env:USERPROFILE.ssh\authorized_keys file.
Yes I kinda guessed that this rule do something like that.
And also me, as I probably suppose some other peoples too, have the only, %username% aka main aka administator aka 'personal' or business etc win account, so that this somewhat 'hidden' tiny littly rule in the end of the default config, which you would at the very end suppose to be the cause of your connectivity problem, that default config instruction in this very basic case (installing ssh on a machine with one main admin account in use), leads to complete block of public key auth which may look as almost undebuggable behavior of the server, if you don't know about this line and what it does and can't match this line, you as a member of administators group, and your final denying of public key auth whilst it should probably be working and internet is happy to give your around 100500 advices about how to fix it but no one of them is about this small config rule, which as I may see is default in releases for quite some time.

Isn't it a more user-friendly or something idea to comment this line by default in config since it will cause unclear public key authentication inability in many percentage of first-try-to-configure attempts, none all of them would finally stood till realizing the role of that last default config file rules, which (config) you would really don't expect to be "not on your side" and be needed to be changed somehow from default original-developers state (as me for the first couple days..)?

[tgauth]

leads to complete block of public key auth

It does not lead to a complete block of public key auth.
It just points the AuthorizedKeysFile to __PROGRAMDATA__/ssh/administrators_authorized_keys for users in the administrator group.

I'm going to close this, as issue #1942 was opened to request additional documentation regarding the administrators_authorized_keys file.

[b-a0]

Edit: nevermind, I found #1324

Original comment:

Is it possible to get more information on the rationale behind placing authorized keys of administrator users in a separate file under ProgramData? Is this more secure than allowing these users to write it to their $env:USERPROFILE\.ssh\authorized_keys file?
In other words: what risks do I introduce if I remove that match group block?

[tjanson]

@b-a0 It seems to me that the current default of a shared admin auth keys file is not just confusing/unexpected but actually less secure. If there are several admin users, should they really have a common auth keys file, so that any keys can be used interchangeably for all admin users? Perhaps a matter of taste, but I certainly don't think so.