Introduction
At the time of writing, the version of OpenSSH shipped for Windows has a default configuration that requires all Administrative user keys to be placed in a single file called administrators_authorized_keys.
This is defined by the Match directive below. When you install the OpenSSH server, it comes with this directive already present in the sshd_config file.
Match Group administrators
AuthorizedKeysFile C:\ProgramData\ssh\administrators_authorized_keys
The reasoning behind this configuration is to prevent a user from bypassing a UAC prompt to gain access to an elevated command prompt. This file is placed under C:\ProgramData\ssh directory and has permissions that require a UAC prompt before a user can change the file.
Demonstrating the problem
When an Administrator uses SSH to log in to Windows, the command prompt is automatically elevated, just like an Administrator has right-clicked on cmd.exe and clicked Run As Administrator. However, the difference is that when connecting with SSH, there is no UAC prompt for the user to accept.
The issue can be easily demonstrated when the server configuration for administrators_authorized_keys is removed.
- On the desktop, open an unelevated command prompt.
- Generate an SSH Key
ssh-keygen - Configure your authorized_keys file with the new key
copy .\.ssh\id_rsa.pub .\.ssh\authorized_keys - ssh into localhost
ssh localhost
Performing the steps above, the user gains an elevated command prompt from an unelevated prompt without any interaction, bypassing the UAC prompt that would typically be presented by running as Administrator.
So how does the configuration solve the problem?
The administrators_authorized_keys location ensures that when authorized keys are edited, the user has been warned that the operation could be dangerous.
Is this a vulnerability?
No, there is no vulnerability here; the Administrator can run an elevated command prompt regardless. It takes more effort for the Administrator to bypass the prompt and more typing than would be necersary accepting a UAC prompt when they perform an operation that requires elevation.
By introducing this configuration, the OpenSSH for Windows developers has introduced more problems. Any Administrator can SSH into a Windows server with another administrator’s username. In effect, all Administrators now share SSH credentials which could be problematic for compliance with security policies and industry standards like HIPPA and PCI-DSS.
The solution
The original problem is a boundary issue. UAC warns the user they are potentially changing sensitive data. It could be mitigated by printing a warning in the SSH banner to warn users about the power that the SSH shell yields.
I believe this configuration should be reversed and that each Administrator should use the standard location for authorized keys at %USERPROFILE%\.ssh\authorized_keys.
Unfortunately, you cannot use the SSH Teams key management solution without reverting this change. This is why when you provision a Windows OpenSSH server with SSH Key Management for Teams, the deployment program will prompt you to confirm it can disable this unhelpful configuration.
Adding a banner
If you want to ensure the Administrator logging into your server is warned. You can always configure the SSH server to give users a banner as they log in.
Create a file only accessible by Administrators, for example, in C:\ProgramData\ssh\UAC.txt
WARNING: Logging in to this server with this account yields all the power of an Administrator. These powers mean that you will not be warned before changing sensitive configurations. You have been warned.
Edit C:\ProgramData\ssh\sshd_config and change or add the Banner directive by reusing the same Match criteria as the original configuration to ensure it is only shown to Administrators.
Match Group administrators
Banner C:\ProgramData\ssh\UAC.txt
Now, at the very minimum Administrative users are warned that there will be no UAC prompt before they change the system.