Repository navigation
Match Group administrators is silently skipped for Entra ID administrators (keys read from per-user authorized_keys) #2466
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest version
- Search the existing issues.
Related: #1787 (SSH with AAD/Entra ID credentials). The behaviour below comes from PowerShell/openssh-portable#744, which made ga_init() non-fatal when no user token can be generated.
Steps to reproduce
- Entra ID–joined Windows 11 device; an Entra ID user (SID
S-1-12-1-…) who is a member of the local Administrators group. - Default
%ProgramData%\ssh\sshd_config, which contains:Match Group administrators AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys - Run
sshd.exe10.0.0.0p2 as SYSTEM (as the service does). For the logs below:sshd.exe -ddd -p 2223 -E log.txtfrom a SYSTEM scheduled task. - Put the user's public key in
C:\Users\<user>\.ssh\authorized_keys. ssh -p 2223 -l 'azuread\<user>' <host>
Expected behavior
The Match Group administrators block applies to an administrator, so their keys are looked up only in administrators_authorized_keys, as documented in OpenSSH key management. If group membership can't be determined, sshd should say so clearly rather than silently treating the user as a non-administrator.
Actual behavior
sshd can't create an S4U token for the Entra ID user (see #1787), so since #744 ga_init() reports the user as being in no groups. The Match Group administrators block is skipped for an Entra ID administrator, and the key is read from the per-user authorized_keys:
checking match for 'Group administrators' user azuread\\<user> host <client> ... lport 2223 on line 87
lookup_principal_name: User principal name lookup failed for user 'azuread\\<user>' (explicit: 1355, implicit: 1355)
debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'azuread\\<user>' Status: 0xC0000062 SubStatus 0.
get_user_token - unable to generate token on 2nd attempt for user azuread\\<user>
ga_init, unable to resolve user azuread\\<user>
debug1: Can't Match group because user azuread\\<user> not in any group at line 87
debug3: match not found on line 87
Accepted key ED25519 SHA256:... found at C:/Users/<user>/.ssh/authorized_keys:1
Accepted publickey for azuread\\<user> from <client> port ... ssh2: ED25519 SHA256:...
(The session then fails with fork of unprivileged child failed, the S4U limitation tracked in #1787.)
Any other Match Group block an admin relies on (e.g. ForceCommand, ChrootDirectory, AllowTcpForwarding) is silently skipped for Entra ID users in the same way, because their membership always reads as "no groups".
Suggestion: when the token can't be generated, resolve membership another way (e.g. the account SID against the local group, including Entra role SIDs nested in Administrators), or at least log a warning that Match Group rules could not be evaluated for that user.
Environment data
Windows 11 Pro 25H2, build 10.0.26200, Entra ID–joined (AzureAdJoined: YES, DomainJoined: NO)
Windows PowerShell 5.1.26100
Version
OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 4.2.0 (GitHub release 10.0.0.0p2-Preview, zip, run as SYSTEM)
Inbox OpenSSH_for_Windows_9.5 (sshd.exe 9.5.6.2) on the same machine fails earlier: ga_init() still calls fatal() there (pre-#744).
Activity
github-actions commentedon Oct 2, 2026
Thanks for the detailed report. This looks like an actionable Windows-specific
sshd/authentication bug: when Entra ID user group resolution fails,Match Group administratorscan be skipped silently and administrative-key policy can be bypassed.For maintainers
ga_init()/group lookup behavior. Confidence: high.10.0p2GitHub preview, with inbox9.5.6.2comparison), server/client environment detail for the Entra-joined Windows 11 machine, exactsshd_configcondition, command/log excerpt, expected behavior, and actual behavior. Confidence: high.Match Grouphandling, but the right fix may involve Windows account/SID semantics and security-sensitive behavior, so maintainer design review is important.Area-sshd,Area-Authentication, andArea-Logging/Diagnostics. The issue affects server-sideMatch Groupevaluation during authentication/authorization, and the fallback/logging behavior when group resolution cannot be evaluated.Related issues and notes
Match groupblocks.ga_init()behavior where an Entra administrator is treated as having no groups and per-userauthorized_keysis accepted despite the default AdministratorsMatch Groupblock.Add this agentic workflows to your repo
To install this agentic workflow, run