Search code examples
sshwindows-server-2012-r2openssh

SSH Config Commenting Out Match Group Administrators

I was struggling with setting up public key authentication via SSH on a Windows Server 2012 R2 instance. I installed OpenSSH on the instance.

I made sure to have the public key on the instance in the ssh folder of the user and tried to SSH in from an instance with the private key. However, I kept being asked for the password.

Finally, I came across this blog which says to comment out the following lines

#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

in the C:\ProgramData\ssh\sshd_config file. After that, I was able to login with the public key.

My question is, why did that work? I've never seen any indication on any other blog that this needs to be done and I'm not sure what commenting those lines does.

Solution

  • This change is introduced in here: Override default location for authorized_keys for administrators by manojampalam · Pull Request #369 · PowerShell/openssh-portable

    And here is the tread discussing this change: Is administrators_authorized_keys a security problem? · Issue #1324 · PowerShell/Win32-OpenSSH

    These two lines redirect the authorized_keys to a path that requires elevated session to make change while you are logging in with a admin account. This is said to prevent an admin login in a non-elevated session, generate a key pair and append the pubkey to authorized_keys in his home path. And then ssh localhost to get a elevated session inside a non-elevated one, which could bypass the UAC. The author of the commit thinks this is a privilege escalation.

    According to the discussion in that thread, this change didn't actually solve any concern, but rather introduced a bunch of new issues. The biggest one is that it breaks the pubkey authentication in non-English environment.

    It introduces a localization issue and even more unexpected behavior. The entry in the default sshd_config reads: Match Group administrators - but that is a localized group name that only applies to english Windows installations. This means that this Match statement only ever matches as intended on english Windows installs, in any other locale the translated name of the S-1-5-32-544 group will not match and the authorized_keys of administrative users will continue to be in their respective userprofile paths - what a mess!

    Source: issuecomment-749098394

    This is the reason I searched for the same issue in midnight and came across your question. Just delete or comment out those two lines.