Win32 OpenSSH broken after KB5074109 update

[timboss]

Prerequisites

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

Steps to reproduce

I am experiencing connectivity issues from CentOS 9 Stream client to Windows 11 PC after latest Windows Update has been installed.

I have manually installed OpenSSH on Windows 11 PC and confirmed all the scripts have been run, and that icacls is applied correctly.

I have been able to connect successfully for several months, and after latest Windows Update, this no longer works

ssh_client_post_update.log
2026-01 Security Update (KB5074109) (26200.7623).txt
icacls.txt
sshd-session_prior_update.log
sshd-session_post_update.log
ssh_client_prior_update.log

Expected behavior

[build@aerotrack.com.au@app-bld-cn9-prd .ssh]$ ssh build@ats-w11-d16

Microsoft Windows [Version 10.0.26100.7462]
(c) Microsoft Corporation. All rights reserved.

ats\build@ATS-W11-D16 C:\Users\build>

Actual behavior

[build@aerotrack.com.au@app-bld-cn9-prd .ssh]$ ssh build@ats-w11-d09

Microsoft Windows [Version 10.0.26100.7462]
(c) Microsoft Corporation. All rights reserved.

ats\build@ATS-W11-D09 C:\Users\build>

Error details

8820 2026-01-19 10:13:07.106 debug1: user: (null): attempt 0 failures 0 [preauth]
8820 2026-01-19 10:13:07.138 debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'ats\\build' Status: 0xC00000BB SubStatus 0.
8820 2026-01-19 10:13:07.283 debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'ats\\build' Status: 0xC00000BB SubStatus 0.
8820 2026-01-19 10:13:07.283 error: get_user_token - unable to generate token on 2nd attempt for user ats\\build
8820 2026-01-19 10:13:07.283 error: ga_init, unable to resolve user ats\\build
8820 2026-01-19 10:13:07.283 debug1: Can't Match group because user ats\\build not in any group at line 85
8820 2026-01-19 10:13:07.283 debug1: user: build: kex_server_update_ext_info: Sending SSH2_MSG_EXT_INFO [preauth]
8820 2026-01-19 10:13:07.283 debug1: user: build: userauth-request for user build service ssh-connection method publickey [preauth]

Environment data

PS C:\Windows\System32> $PSVersionTable

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

Version

PS C:\Windows\System32> ssh -V OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 4.2.0

Visuals

No response

[timboss]

Correction, Actual Behavior is

[build@aerotrack.com.au@app-bld-cn9-prd .ssh]$ ssh build@ats-w11-d16
Read from remote host ats-w11-d16: Connection reset by peer
Connection to ats-w11-d16 closed.
client_loop: send disconnect: Broken pipe
[build@aerotrack.com.au@app-bld-cn9-prd .ssh]

[tgauth]

Have you tried updating again? I'm not sure if it would be related, but there is a known issue in the update relating to "Connection and Authentication failures in Azure Virtual Desktop and Windows 365" See https://support.microsoft.com/en-gb/topic/january-13-2026-kb5074109-os-builds-26200-7623-and-26100-7623-3ec427dd-6fc4-4c32-a471-83504dd081cb

[tim-aerotrack]

Have you tried updating again? I'm not sure if it would be related, but there is a known issue in the update relating to "Connection and Authentication failures in Azure Virtual Desktop and Windows 365" See https://support.microsoft.com/en-gb/topic/january-13-2026-kb5074109-os-builds-26200-7623-and-26100-7623-3ec427dd-6fc4-4c32-a471-83504dd081cb

Yes, with no success, still have the repeatable issue. I have hidden this windows update in the interim. If I remove the users authorized_keys file, then ssh from unix PC works, but requires a password

[jkittner]

This is exactly the behavior we are also running into. Updating again (today) did not fix anything.

So how would hiding the update look like and did it actually fully restore the old behavior? When and in what form can one expect a fix of the broken update?

[tim-aerotrack]

@jkittner Latest Windows Update (KB5077181) also breaks this functionality and I have had to hide these Windows Updates from being installed. We are a small shop, so use SAMBA 4 for Windows Domain Authentication. What is your domain authentication server, Windows or Linux?

[jkittner]

Mhm, the only updates that were recently installed are KB2267602, KB5066738, KB25383242, KB5066143, KB890830, KB5075904, and KB2565063. From which I can only see a few of them under "installed updates". This is on Windows Server 2019.
Iirc it's LDAP on linux.

[jkittner]

Uninstalling KB5075904 fixed the problem for us. I can now authenticate again using the public key. So I will hide that update for now.

[tgauth]

Would either of you be willing to provide additional info from the auth log? https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/basic-audit-logon-events

[tim-aerotrack]

Audit Logs.zip
Sure, I will provide logs when it was working pre Windows Updates and then post Windows Updates

[tim-aerotrack]

Please note, when I remove or rename local authorized_keys file in users .ssh folder, I am able to connect from the linux PC to the windows PC via ssh with password.

It only when using no password with authorized_keys file, where it no longer works after the latest 3 Windows Updates

[ahmedtpawsey]

Please note, when I remove or rename local authorized_keys file in users .ssh folder, I am able to connect from the linux PC to the windows PC via ssh with password.

It only when using no password with authorized_keys file, where it no longer works after the latest 3 Windows Updates

Yes, as far as I have understood it, the issue is related to how the auth talks back to the AD server to create the token: generate_s4u_user_token and this happens before it can verify the password from AD. It fails at that point. Whereas if you remove the key, it will prompt you to log in with a password, which will work but, you can't set the group to who should have ssh access, it will be for "all". If you try to configure e.g. AllowGroups Administrators it will again fail with the s4u token error.

Key points:

• S4U token generation happens before password validation —> it fails at this checkpoint
• Removing/renaming authorized_keys forces password auth, bypassing S4U entirely (password auth uses LogonUser() directly)
• AllowGroups fails because it relies on S4U to resolve group membership; S4U fails, so the connection terminates before group checks can occur

What I was just looking for though is this affecting all versions of openssh?
I am on

ssh -V
OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2

$PSVersionTable

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

[tim-aerotrack]

ssh -V
OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 4.2.0
$PSVersionTable

Name Value

---

PSVersion 5.1.26100.7920
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.26100.7920
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[timboss]

Any progress on this from the audit logs??