镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Intermittent SSH Connection Delays (~15-120 seconds) on Windows OpenSSH 10.0 #2425

Open

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:

  1. Connection delays occur between sshd-session.exe -R subprocess spawn and actual connection handling
  2. Delays range from 15-120 seconds, making automation and Ansible tasks timeout
  3. Pattern is inconsistent but reproducible (occurs in ~10% of connection attempts)
  4. No resource exhaustion detected; system remains responsive
  5. 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:

  1. When did this issue first appear? This happens in both v9.2.0.0 and v10.0.0.0
  2. Is there a specific Windows configuration? There are no domain credentials only local accounts using public key authentication.
  3. 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 cases

Environment 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.0

Version

v10.0.0.0, but upgraded from v9.2.0.0 to test if latest version fixes this issue

Visuals

No response

Activity

  1. tgauth commented on Feb 23, 2026

    @tgauth
    Collaborator

    Have you tested with any version older than v9.2?

  2. jimroberts-tamu commented on Feb 26, 2026

    @jimroberts-tamu
    Author

    Trying out 9.1.0.0. Thanks for the response!

  3. jimroberts-tamu commented on Feb 26, 2026

    @jimroberts-tamu
    Author

    I just installed 9.1.0.0 and similar results. My very first connection was fast though (332ms), but after letting it set idle for 15 minutes, my first connection was 48 seconds.

  4. jimroberts-tamu commented on Mar 31, 2026

    @jimroberts-tamu
    Author

    Hi Tess Gauthier (@tgauth), do you have any other suggestions?

  5. yankaiqian commented on Apr 30, 2026

    @yankaiqian

    #1817
    please refer to this issue, create a local user named "sshd" may solve the delay issue.

  6. jimroberts-tamu commented on Apr 30, 2026

    @jimroberts-tamu
    Author

    yankaiqian, thanks for your response.

    Unfortunately, that is a different condition. If that is happening to us, it has gone unnoticed. The condition of that issue is that sshd takes 5 minutes to start. In our case sshd is already running and the slowness is incurred when it tries to start sshd-session.

    I'm in the process of isolating the issue using ProcMon. I'm currently investigating why even though I'm using a local account, lsass is still timing out.

    Additional observation: on my test server it is consistently between 47 and 48 seconds of delay and after the delay the connections become very fast again (sub second) and continue for ~92 seconds until the next delay occurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions