You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ssh.exe hangs when started via Task Scheduler API unless -v or -E is specified #2448
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.
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.
Activity
tgauth commentedon Aug 3, 2026
This sounds like it could be an issue with the handle inheritance because of the async nature of
Start-ScheduledTaskandschtasks /Runjborean93 commentedon Aug 5, 2026
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 thatsshisn't trying to flush and console buffer withIt is interesting that adding
-vor-Estops this but I cannot honestly explain what's happening there sorry.yy8091-gmail commentedon Aug 5, 2026
I tested the suggested options.
Results:
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.