OWNER RIGHTS not allowed on identity file ACL, even if owner is in Administrators

[hssyoo]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

When a private key identity file has the OWNER RIGHTS group permission attached and the file is owned by an administrator, the OpenSSH client fails with a warning that the file's permissions are too open:

> ssh -p port -i C:\Path\To\TempDir\Keyfile destination

Bad permissions. Try removing permissions for user: \\OWNER RIGHTS (S-1-3-4) on file C:\Path\To\TempDir\Keyfile.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\Path\To\TempDir\Keyfile' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "C:\Path\To\TempDir\Keyfile": bad permissions
destination: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

My understanding is that only administrators and System can have access to the key file. It looks like the client explicitly checks for the admin and system SIDs, but does not follow an owner rights SID and checks that the file is owned by an admin. I was curious if maintainers would be open to allowing OWNER RIGHTS provided that the owner is an admin.

Related:

• OpenSSH incompatible with mkdir(mode=0o700) on Windows with OWNER RIGHTS python/cpython#128038

Expected behavior

# Identity file with `OWNER RIGHTS` permissions attached
> ssh -p port -i C:\Path\To\TempDir\Keyfile destination

# SSH succeeds
Last login: Tue Dec 17 20:44:37 2024 from foo

Actual behavior

# Identity file with `OWNER RIGHTS` permissions attached
> ssh -p port -i C:\Path\To\TempDir\Keyfile destination

# SSH fails
Bad permissions. Try removing permissions for user: \\OWNER RIGHTS (S-1-3-4) on file C:\Path\To\TempDir\Keyfile.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\Path\To\TempDir\Keyfile' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "C:\Path\To\TempDir\Keyfile": bad permissions
destination: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.20348.2760
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.20348.2760
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version

9.5

Visuals

[zooba]

To add the nuance that has led us to this point, it turns out that if you create an ACL as CURRENT USER with an elevated token, the owner is the Administrators group but the non-elevated user has been granted access. When you create the ACL as OWNER RIGHTS with an elevated token, the Administrators group gets the access, and so the current user has to be running with their elevated token.