sshd-session.exe crashes with 0xc0000005 after password auth on domain-joined Windows 10

Summary

sshd-session.exe (v10.0.0.0) and sshd.exe (v9.5.4.1) crash with access violation (0xc0000005) immediately after accepting password authentication on a domain-joined Windows 10 machine. The crash occurs in the child/session process after successful authentication, before a shell is spawned. The connection resets from the client's perspective.

Both the Windows Feature (v9.5.4.1) and the MSI release (v10.0.0.0) exhibit the same crash at different offsets.

Environment

• OS: Windows 10 Pro 22H2 (10.0.19045)
• Architecture: AMD64
• Domain-joined: Yes (axcend.local)
• Hypervisor: Xen 4.17 (HVM domU)
• User account: Local administrator (EmpowerW10\Axcend), member of BUILTIN\Administrators
• OpenSSH v9.5.4.1: C:\Windows\System32\OpenSSH\sshd.exe (Windows Feature)
• OpenSSH v10.0.0.0: C:\Program Files\OpenSSH\sshd.exe (MSI install)

Reproduction Steps

1. Install OpenSSH Server on a domain-joined Windows 10 machine
2. Enable and start the sshd service
3. Connect from a remote machine using password authentication:

   ssh -o PreferredAuthentications=password "EmpowerW10\Axcend@<ip>"
   

4. Enter the correct password
5. Connection immediately resets after password is accepted

Observed Behavior

The OpenSSH event log shows a consistent pattern:

sshd-session: Connection from 10.8.0.6 port 59256 on 192.168.0.88 port 22
sshd-session: Accepted password for EmpowerW10\Axcend from 10.8.0.6 port 59256 ssh2
sshd-session: User child is on pid 10620
sshd-session: Invalid user axcend from 10.8.0.6 port 59256

Password is accepted for the domain-qualified name (EmpowerW10\Axcend), but the session process then logs "Invalid user axcend" (bare username) and crashes.

Crash details — v10.0.0.0 (sshd-session.exe)

Faulting application name: sshd-session.exe, version: 10.0.0.0, time stamp: 0x68f92f6a
Faulting module name: sshd-session.exe, version: 10.0.0.0, time stamp: 0x68f92f6a
Exception code: 0xc0000005
Fault offset: 0x0000000000034aa3
Faulting application path: c:\program files\openssh\sshd-session.exe

Crash details — v9.5.4.1 (sshd.exe)

Faulting application name: sshd.exe, version: 9.5.4.1, time stamp: 0x67bf20a8
Faulting module name: sshd.exe, version: 9.5.4.1, time stamp: 0x67bf20a8
Exception code: 0xc0000005
Fault offset: 0x000000000003a37a
Faulting application path: C:\Windows\System32\OpenSSH\sshd.exe

Both crashes are reproducible 100% of the time. WER crash dumps are available locally.

sshd_config (relevant non-default lines)

SyslogFacility AUTH
LogLevel DEBUG3
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
Subsystem sftp sftp-server.exe
# Match Group administrators block is commented out

What was verified

• Firewall rules allow inbound TCP 22 (confirmed with netstat — sshd.exe is listening on 0.0.0.0:22)
• User account is active, local admin, member of BUILTIN\Administrators
• Password was set and accepted (event log confirms Accepted password)
• Host key permissions are correct (SYSTEM + Administrators only)
• DefaultShell registry key is not set (defaults to cmd.exe, which exists)
• No SeDenyNetworkLogonRight for the user
• No NTFS alternate data streams on config files
• The crash also occurs via Tailscale IP (different network interface), ruling out network issues

Likely root cause

The "Invalid user axcend" message after "Accepted password for EmpowerW10\Axcend" suggests the session process fails to resolve the bare username during post-auth user profile loading on the domain-joined machine. The access violation likely occurs in user token creation or profile loading code when the local account name collides with or cannot be resolved against the domain.

Related Issues

• #1924 — "Connection drops after authentication" (open, similar symptoms)
• #2011 — Same 0xc0000005 crash, claimed fixed in v9.1 via PR openssh-portable#616, but regression persists
• #2435 — load_user_profile format-string crash in sshd-session post-auth (different trigger, same crash surface)

Start with the post-auth session path around load_user_profile and the sshd-session entry point; compare the accepted domain-qualified name with the later bare-name lookup and inspect the available WER crash dumps. Re-run the documented password-authentication steps on a domain-joined Windows 10 host; done means the session no longer crashes or resets after authentication and reaches the shell.