-
Notifications
You must be signed in to change notification settings - Fork 805
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest version
- Search the existing issues.
Steps to reproduce
Environment:
- OpenSSH Version: 10.0.0.0 (Win32-OpenSSH-GitHub)
- Windows Version: Windows Server 2016 thru 2025
- Client: OpenSSH 8.9p1 (Ubuntu Linux)/OpenSSH Windows 9.5p2
- Authentication: ED25519 public key, local user account
Description:
SSH connections to a Windows OpenSSH 10.0 server experience intermittent delays of 15-120 seconds during the subprocess initialization phase. The issue occurs unpredictably—sometimes allowing 18+ consecutive fast connections before a pause occurs, other times pausing after just a few connections. System resources (CPU <10%, RAM ~2GB/4GB) remain stable throughout.
Symptoms:
- Connection delays occur between
sshd-session.exe -Rsubprocess spawn and actual connection handling - Delays range from 15-120 seconds, making automation and Ansible tasks timeout
- Pattern is inconsistent but reproducible (occurs in ~10% of connection attempts)
- No resource exhaustion detected; system remains responsive
- Issue persists across multiple test runs
Root Cause Analysis:
Server-side logs show the delay occurs during:
debug3: spawning "c:\\program files\\openssh/sshd-session.exe" -R as subprocess
[~34-47 second gap here]
debug1: Connection from X.X.X.X port XXXXX on X.X.X.X port 22
The gap occurs before the session subprocess even begins processing the SSH protocol, indicating a Windows process creation/initialization issue rather than network or authentication delays [2].
Log Evidence:
Server logs (sshd-session.log):
NNNN 2026-02-18 HH:MM:SS.123 debug3: spawning "c:\\program files\\openssh/sshd-auth.exe" -R as user
NNNN 2026-02-18 HH:MM:SS.124 debug2: Network child is on pid NNNN
NNNN 2026-02-18 HH:MM:SS.150 debug3: preauth child monitor started
NNNN 2026-02-18 HH:MM:SS.180 debug3: mm_request_receive: entering
[Process continues normally at this point]
Main process logs (sshd.log):
NNNN 2026-02-18 HH:MM:SS.692 debug3: spawning "c:\\program files\\openssh/sshd-session.exe" -R as subprocess
NNNN 2026-02-18 HH:MM:SS.755 debug2: server_accept_loop: child NNNN for connection received config
[~63 millisecond delay between spawn and handling]
Post-session cleanup shows potential lock contention:
NNNN 2026-02-18 HH:MM:SS.XXX debug1: user: clat-ansible: do_cleanup [postauth]
NNNN 2026-02-18 HH:MM:SS.XXX debug3: mm_request_receive: entering
NNNN 2026-02-18 HH:MM:SS.XXX debug3: mm_request_receive: monitor fd closed
NNNN 2026-02-18 HH:MM:SS.XXX debug1: mm_reap: preauth child exited with status 255
Questions for clarification:
- When did this issue first appear? This happens in both v9.2.0.0 and v10.0.0.0
- Is there a specific Windows configuration? There are no domain credentials only local accounts using public key authentication.
- Has there been any Windows-specific changes?: This effects hosts that have and have not had changes in the past 2 years. No noticeable correlation in configuration or OS. Client is both Ubuntu (most often from Ansible) as well as Windows 11 and Windows Server 2022.
Expected behavior
SSH connections should establish consistently within 1-2 seconds regardless of prior connection history.Actual behavior
Inconsistently connecting between 500ms and 2 minutes.Error details
No noticeable errors other than timeouts in some casesEnvironment data
Name Value
---- -----
PSVersion 5.1.20348.4294
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.20348.4294
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Have also tested with PowerShell Core:
Name Value
---- -----
PSVersion 7.5.4
PSEdition Core
GitCommitId 7.5.4
OS Microsoft Windows 10.0.20348
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Version
v10.0.0.0, but upgraded from v9.2.0.0 to test if latest version fixes this issue
Visuals
No response