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
- Install OpenSSH Server on a domain-joined Windows 10 machine
- Enable and start the
sshd service
- Connect from a remote machine using password authentication:
ssh -o PreferredAuthentications=password "EmpowerW10\Axcend@<ip>"
- Enter the correct password
- 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
Summary
sshd-session.exe(v10.0.0.0) andsshd.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
axcend.local)EmpowerW10\Axcend), member ofBUILTIN\AdministratorsC:\Windows\System32\OpenSSH\sshd.exe(Windows Feature)C:\Program Files\OpenSSH\sshd.exe(MSI install)Reproduction Steps
sshdserviceObserved Behavior
The OpenSSH event log shows a consistent pattern:
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)Crash details — v9.5.4.1 (
sshd.exe)Both crashes are reproducible 100% of the time. WER crash dumps are available locally.
sshd_config (relevant non-default lines)
What was verified
netstat—sshd.exeis listening on0.0.0.0:22)BUILTIN\AdministratorsAccepted password)SYSTEM+Administratorsonly)DefaultShellregistry key is not set (defaults tocmd.exe, which exists)SeDenyNetworkLogonRightfor the userLikely 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
strstrcall indo_exec_windows) #2011 — Same0xc0000005crash, claimed fixed in v9.1 via PR openssh-portable#616, but regression persistsload_user_profileformat-string crash insshd-sessionpost-auth (different trigger, same crash surface)