ssh.exe hangs when started via Task Scheduler API unless -v or -E is specified

[yy8091-gmail]

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

• Windows Server 2025
• OpenSSH_for_Windows_9.5p2
• Windows PowerShell 5.1
• Remote server: Debian 13 (OpenSSH_10.0p2)
• ED25519 public key authentication

The scheduled task executes:

powershell.exe -ExecutionPolicy Bypass -File D:\archive\bin\archive_job.ps1

The PowerShell script runs:

Write-Host "Create remote directory..."

ssh `
    -i $TransferKey `
    "$TransferUser@$TransferHost" `
    "mkdir -p '$RemoteDir'"

The message Create remote directory... is printed immediately before ssh.exe is started.

Reproduction result

The issue occurs only when the scheduled task is started through:

• Start-ScheduledTask
• schtasks /Run

The following execution methods work correctly:

• Running archive_job.ps1 directly from PowerShell
• Clicking "Run" from the Task Scheduler GUI

When the issue occurs, PowerShell prints:

Create remote directory...

and never returns from the ssh command.

No further output is produced.

Expected behavior

ssh.exe should complete normally regardless of how the scheduled task is started.

Starting a task through Task Scheduler API should behave the same as running the task from the Task Scheduler GUI or executing the PowerShell script directly.

Actual behavior

When the scheduled task is started through Start-ScheduledTask or schtasks /Run, ssh.exe hangs.

The script prints "Create remote directory..." immediately before starting ssh.exe, then PowerShell never returns from the ssh command.

The remote command is not completed from the client's point of view.

Error details

No PowerShell exception is generated.

PowerShell simply waits indefinitely for ssh.exe to exit.

Environment data

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

Version

OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2

Visuals

Additional observations:

Adding either of the following options completely avoids the issue:

ssh -v ...

ssh -vvv ...

ssh -E D:\archive\ssh_debug.log ...

All three complete successfully.

The issue only occurs with a normal ssh invocation without debugging options.

When using -vvv, the SSH debug log shows:

• Authentication succeeds.
• The remote command is sent successfully.
• Exit status is 0.
• The SSH session closes normally.

The Debian OpenSSH server also reports a successful authentication and command execution.

Therefore, this appears to be a client-side issue triggered only when ssh.exe is started through the Task Scheduler API.

[tgauth]

This sounds like it could be an issue with the handle inheritance because of the async nature of Start-ScheduledTask and schtasks /Run

[jborean93]

If running this in a scheduled task I would highly encourage you to specify options that disable user interaction, e.g. ssh -o BatchMode=yes ... will ensure that any prompts, like falling back to password auth, will not occur and ssh won't hang. You have a few other options that could try and disable any forced console interaction like -T (disable PTY) and -n (no stdin) but I'm unsure whether the Win32 ssh.exe client do anything with those. You could also look at forcing pwsh to redirect the stdout and stderr so that ssh isn't trying to flush and console buffer with

ssh.exe ... 2>&1 | Out-String

It is interesting that adding -v or -E stops this but I cannot honestly explain what's happening there sorry.

[yy8091-gmail]

I tested the suggested options.

Results:

• No option: hangs
• -v: works
• -E: works
• -o BatchMode=yes: works
• -n: works
• -T: still hangs

It seems that disabling stdin (-n) or preventing any interactive authentication (BatchMode=yes) avoids the issue, while disabling PTY (-T) does not.

I hope this helps narrow down the cause.