ssh-agent (10.4.0.0p1-Preview) fails to start on one Windows 11 26300 machine: cannot create agent root reg key, ERROR:5

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest version
Search the existing issues.

Steps to reproduce

Project: PowerShell/Win32-OpenSSH (the OpenSSH for Windows port).
This is NOT a PowerShell engine issue — filed here because this repo has no
issue template of its own.

Environment: Windows 11 Pro for Workstations 10.0.26300 (x64),
OpenSSH_for_Windows_10.4p1 (LibreSSL 4.3.3), unpacked from OpenSSH-Win64.zip
(10.4.0.0p1-Preview).

In an elevated PowerShell:

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\ssh-agent' `
    -Name ImagePath -Value 'C:\tools\openssh-10.4\ssh-agent.exe'
Set-Service ssh-agent -StartupType Manual
sc.exe start ssh-agent
Start-Sleep 4
sc.exe queryex ssh-agent
Get-WinEvent -LogName 'OpenSSH/Admin' -MaxEvents 1

These exact steps on a second Windows 11 10.0.26300 machine, with the same
binary and the same registry/service state, leave the service RUNNING.

Expected behavior

SERVICE_NAME: ssh-agent
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)

Actual behavior

SERVICE_NAME: ssh-agent
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 1067  (0x42b)
        SERVICE_EXIT_CODE  : 0  (0x0)

Error details

OpenSSH/Admin — Event ID 1 (Critical):
    ssh-agent: fatal: cannot create agent root reg key, ERROR:5

System — Event ID 7034 (on every attempt):
    The OpenSSH Authentication Agent service terminated unexpectedly.

Process Monitor, filter "Process Name is ssh-agent.exe", during the failed start:

  RegOpenKey    HKLM\System\CurrentControlSet\Services\WinSock2\Parameters
                ACCESS DENIED   Desired Access: All Access

  RegCreateKey  HKLM\SOFTWARE\OpenSSH
                SUCCESS         Desired Access: Maximum Allowed,
                                Granted Access: Read, Create Link

  RegCreateKey  HKLM\SOFTWARE\OpenSSH\Agent
                ACCESS DENIED   Desired Access: Write

No WER dump is produced even with LocalDumps configured for ssh-agent.exe —
the process exits cleanly rather than crashing.

Two-machine comparison

	A (fails)	B (works)
OS build	10.0.26300	10.0.26300
Binary	OpenSSH_for_Windows_10.4p1, same sha256	same file
`HKLM\SOFTWARE\OpenSSH\Agent`	owner SYSTEM, SDDL `O:SYG:SYD:PAI(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)`, value `ProcessID`	identical
Service	LocalSystem / SID_TYPE UNRESTRICTED / same `sc privs`	identical
IFEO `MitigationOptions`	`00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10` (19 bytes)	identical
Defender ASR / Controlled Folder Access	none configured	none configured
WDAC policy files	8	8, same file names
Secure Boot	Enabled (also tested Disabled, see 13)	Disabled
Hardware	Ryzen 9 9950X3D desktop	Ryzen 3 3250U laptop

What has already been ruled out

Both machines: identical OS build (10.0.26300), same binary
(sha256 B67FF8BECD203502190EC42AC7787C24C2CD3325ED7700485FE7A1C83D2A7957),
same registry ACLs, same service config, same security posture. Only machine A fails.

Binary / package integrity — same zip extracted on machine B → RUNNING.
Path depth / drive — copied to the identical D:\git\...\_tools\openssh-10.4
path on B → RUNNING.
Service ACL & privileges — sc sdshow / sc qprivs already match install-sshd.ps1.
Registry key owner / DACL — applying the installer's exact SDDL and owner
(with SeRestorePrivilege enabled) changes nothing.
RedirectionGuard — deleting the IFEO MitigationOptions value → still ERROR:5.
Pre-existing key state — deleting HKLM\SOFTWARE\OpenSSH\Agent entirely →
same error, and the key is not recreated.
Pre-creating keys — HKLM\SOFTWARE\OpenSSH\Agent\Keys and
HKU\S-1-5-18\Software\OpenSSH\Agent\Keys → no change.
Leftover ProcessID value — adding the same value on machine B does not break it.
Reboot — reproduces identically after clean restarts (4 times).
Defender ASR / Controlled Folder Access / third-party AV — none on either machine.
%PATH% version mixing (the cause diagnosed in cannot create agent root reg key, ERROR:5 #285) — ruled out both directions:
adding the 10.4 dir before System32\OpenSSH on B (with reboot) does not break it;
removing it entirely from the machine PATH on A (with reboot) does not fix it.
VBS / HVCI / WDAC / Smart App Control — disabling the hypervisor on A
(bcdedit /set {current} hypervisorlaunchtype off + reboot, so HypervisorPresent=False
and VBS status=0, matching machine B) → still ERROR:5.
Secure Boot — disabling it in firmware on A and rebooting → still ERROR:5.

After the above, no known configuration difference remains between the two machines.

The decisive oddity

Pointing the same service at cmd.exe /c <script> (running as LocalSystem) and doing
reg add "HKLM\SOFTWARE\OpenSSH\__svcprobe" returns errorlevel 0 (success) on the
failing machine. So the service account itself can write that key — only
ssh-agent.exe cannot. This suggests the agent performs part of its initialisation
with a less-privileged effective token (impersonation / restricted token), and that
this path behaves differently on this machine.

Related issues

cannot create agent root reg key, ERROR:5 #285 — same error string, closed 2016; diagnosed as a %PATH% version mix-up
(ruled out here in both directions, see item 11).
sshd and ssh-agent not registered on 21H1 #1794 — services not registered at all; a different failure.

Questions

Which registry key exactly is the "agent root reg key", and with which samDesired?
Does the agent pass a SECURITY_ATTRIBUTES (owner = BUILTIN\Administrators) to
RegCreateKeyEx? If so, that requires SeRestorePrivilege to be enabled in the
token, not merely assigned via sc privs.
Any known incompatibility between the 10.4 agent and Windows 11 build 26300 when
HKLM\SOFTWARE\OpenSSH pre-exists from an older install?

Additional observations

The inbox 9.5p2 agent runs correctly on machine A — only the 10.4 build fails there.
No WER dump is produced even with LocalDumps\ssh-agent.exe configured (DumpType=2),
i.e. the process returns and exits rather than crashing.
strings on both 9.5p2 and 10.4p1 shows the same symbol set
(StartServiceCtrlDispatcherW, RegisterServiceCtrlHandlerW, SetServiceStatus,
\\.\pipe\openssh-ssh-agent, SOFTWARE\OpenSSH\Agent, SOFTWARE\OpenSSH\Agent\Keys,
RegOpenCurrentUser, cannot create agent root reg key, ERROR:%d) — same code generation.

Environment data

Name                           Value
----                           -----
PSVersion                      7.6.9
PSEdition                      Core
GitCommitId                    7.6.9
OS                             Microsoft Windows 10.0.26300
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.4
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

OpenSSH 10.4.0.0p1-Preview (OpenSSH_for_Windows_10.4p1, LibreSSL 4.3.3) PowerShell 7.6.9

Visuals

No response

This is a well-documented Windows-specific ssh-agent service-startup regression that is ready for maintainer investigation.

For maintainers

Windows-specific vs. parity: Windows-specific bug; high confidence. The failing path involves the Windows service, LocalSystem token behavior, Win32 registry access under HKLM\\SOFTWARE\\OpenSSH, and a Windows-only event log diagnostic. A fix would belong in PowerShell/openssh-portable, not upstream OpenSSH. This is not an upstream-parity feature request.
Reproducibility: The report provides the OpenSSH-for-Windows version, Windows server/host OS build, exact service-start commands, expected and actual output, a same-build control machine, and extensive ruled-out causes. The procedure is clear, but reproduction confidence is medium because the same binary and nominal configuration work on the comparison machine and the remaining trigger is unknown.
Copilot-fix suitability: Maybe. The likely code path is narrow (Windows ssh-agent service registry initialization), but identifying the machine-specific token/registry condition may require maintainer diagnostics before a safe patch can be specified.
Likely area: ssh-agent, specifically Windows service startup and creation/opening of the agent registry root; logging around the failing Win32 registry call may also help distinguish token, requested-access, and security-descriptor behavior.

Related reports and triage notes

cannot create agent root reg key, ERROR:5 #285 is closed and contains the same error text, but its confirmed cause was PATH/version mixing; this report tests and rules out that cause in both directions, so it is not treated as a duplicate.
sshd and ssh-agent not registered on 21H1 #1794 is open, but concerns services not being registered rather than an installed ssh-agent service exiting during registry initialization, so it is not the same root cause.
The inbox 9.5p2 agent working on the affected machine while the 10.4 preview fails supports regression classification.

Suggested first diagnostic

Compare the 9.5p2 and 10.4 Windows agent startup paths at the SOFTWARE\\OpenSSH\\Agent create/open call, including the effective token, requested registry access mask, and any supplied security descriptor. Capturing those values in diagnostic logging would help isolate why only the newer binary receives ERROR_ACCESS_DENIED on this machine.

The repository troubleshooting checklist may also help collect any additional traces maintainers request: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Generated by Agentic Issue Triage for #2486 · copilot · gpt56 · ~26 AIC · ⌖ ~13 AIC · ⊞ 21.7K · ◷

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@2f03fdaafb8c1ae62dfde7e0be762a822a201aeb

Follow-up: 9.5p2 vs 10.4p1 on the same machine

The "suggested first diagnostic" above can already be answered. I captured the startup of both agents on the same machine — same service, same LocalSystem account, same registry state — with Process Monitor (filter: Process Name is ssh-agent.exe).

9.5p2 (inbox, works) — PID 2808

RegOpenKey    HKLM\System\CurrentControlSet\Services\WinSock2\Parameters
              SUCCESS        Desired Access: All Access

RegCreateKey  HKLM\SOFTWARE\OpenSSH\Agent
              SUCCESS        Desired Access: Write, Disposition: REG_OPENED_EXISTING_KEY

RegSetValue   HKLM\SOFTWARE\OpenSSH\Agent\ProcessID
              SUCCESS        Type: REG_DWORD, Length: 4, Data: 2808

0 ACCESS DENIED results for the whole process.

10.4p1 (fails) — PID 14372

RegOpenKey    HKLM\System\CurrentControlSet\Services\WinSock2\Parameters
              ACCESS DENIED  Desired Access: All Access

RegCreateKey  HKLM\SOFTWARE\OpenSSH
              SUCCESS        Desired Access: Maximum Allowed,
                             Granted Access: Read, Create Link

RegCreateKey  HKLM\SOFTWARE\OpenSSH\Agent
              ACCESS DENIED  Desired Access: Write

2 ACCESS DENIED results, exactly the two shown above.

What this establishes

The registry DACL on this machine is not the problem. 9.5p2 obtains All Access and
Write on exactly the same keys, seconds apart, under the same account and the same
service configuration. Any theory that requires a damaged ACL / owner / hive state is
excluded by this.
10.4p1 runs with a more restricted effective token when it makes these calls. Even
HKLM\System\CurrentControlSet\Services\WinSock2\Parameters, which grants SYSTEM full
control on this machine, is denied with Desired Access: All Access.
There is also a code-path difference worth noting: 9.5p2 creates the subkey using the
full path (RegCreateKey HKLM\SOFTWARE\OpenSSH\Agent), so the kernel opens the parent with
KEY_CREATE_SUB_KEY and the call succeeds. 10.4p1 instead opens the parent explicitly first
(HKLM\SOFTWARE\OpenSSH, MAXIMUM_ALLOWED) and is only granted Read, Create Link — which
does not include KEY_CREATE_SUB_KEY — so the subsequent subkey creation must fail.

Interpretation

Both binaries contain the same symbol set for service startup and the same registry paths, and
neither is affected by the environment (9.5p2 proves the environment is fine). The regression is
therefore in how the 10.4 agent establishes or holds its security context during startup.

It would help to know whether the 10.4 agent deliberately drops privileges (restricted token or
impersonation) during initialisation. If it does not, then the service is failing to run with the
token services.exe handed to it — which would point at the service startup path rather than at
the registry code.

Either way, logging the effective token's SIDs and the exact samDesired at the
SOFTWARE\OpenSSH\Agent create call would pin this down immediately.

Additional finding: the foreground (`-d`) agent terminates after serving a single request

While investigating the service-startup failure, I ran the same binary in its foreground mode
(ssh-agent.exe -ddd) from an elevated console on the same machine. It starts correctly —
creates HKLM\SOFTWARE\OpenSSH\Agent, publishes ProcessID, and creates
\\.\pipe\openssh-ssh-agent — but it exits after handling exactly one client request, with
exit code 0:

agent_start pid:18156, dbg:1
client pid 9980 connected
agent_process_connection pipe:00000000000000E0
debug1: get_con_client_info: sshagent_con_username: w256
debug1: client type: administrator
debug3: connection io 0000016B816CBD90 #bytes:0 state:0
debug3: connection io 0000016B816CBD90 #bytes:4 state:1
debug3: connection io 0000016B816CBD90 #bytes:1 state:2
debug1: process agent request type 11          <-- SSH2_AGENTC_REQUEST_IDENTITIES (ssh-add -l)
debug3: connection io 0000016B816CBD90 #bytes:87 state:3
debug1: connection 0000016B816CBD90 clean up
debug3: pkcs11_terminate: terminating 0 helpers
debug1: iocp error: 6 on 0000000000000000      <-- ERROR_INVALID_HANDLE

After that the process is gone (exit code 0), the named pipe is gone, and every subsequent
ssh-add reports Error connecting to agent: No such file or directory.

Reproduction

# elevated PowerShell
$p = Start-Process "C:\tools\openssh-10.4\ssh-agent.exe" -ArgumentList '-ddd' `
        -RedirectStandardError "$env:TEMP\agent_err.txt" -PassThru -NoNewWindow
Start-Sleep 2
"alive = $(-not $p.HasExited)"     # True
ssh-add -l                          # succeeds, lists the identity
Start-Sleep 1
"alive = $(-not $p.HasExited)"     # False
"exit  = $($p.ExitCode)"            # 0
Get-Content "$env:TEMP\agent_err.txt"

Request type 11 is served correctly (the identity list comes back), so this is not a protocol
problem — the listener simply stops after the first connection is cleaned up.

The same binary fails at startup when started with a MEDIUM integrity token

Started from an elevated console the -ddd agent runs. Started from a normal console it
still dies at startup:

agent_start pid:10360, dbg:1
cannot create agent root reg key, ERROR:5

At the same moment, the same MEDIUM token can write to that key:

> reg add "HKLM\SOFTWARE\OpenSSH\Agent" /v __probe__ /t REG_DWORD /d 1 /f
The operation completed successfully.

So the ERROR:5 is not an ACL problem: the caller is allowed to write the key, yet
RegCreateKeyExW(..., KEY_WRITE, &sa, ...) still fails once the SECURITY_ATTRIBUTES argument is
involved. That structure is built in agent_start() (contrib/win32/win32compat/ssh-agent/agent.c):

memset(&sa, 0, sizeof(SECURITY_ATTRIBUTES));
sa.nLength = sizeof(sa);

/* SDDL - FullAcess to System and Builtin/Admins */
sddl_str = L"D:PAI(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)";
if (!ConvertStringSecurityDescriptorToSecurityDescriptorW(sddl_str, SDDL_REVISION_1,
    &sa.lpSecurityDescriptor, &sa.nLength))
        fatal("cannot convert sddl ERROR:%d", GetLastError());
if ((r = RegCreateKeyExW(HKEY_LOCAL_MACHINE, SSH_AGENT_ROOT, 0, 0, 0, KEY_WRITE, &sa,
    &agent_root, 0)) != ERROR_SUCCESS)
        fatal("cannot create agent root reg key, ERROR:%d", r);

The last parameter of ConvertStringSecurityDescriptorToSecurityDescriptorW is the output
size of the security descriptor, so sa.nLength is overwritten with the SD length instead of
remaining sizeof(SECURITY_ATTRIBUTES) — i.e. the SECURITY_ATTRIBUTES handed to
RegCreateKeyExW has an invalid nLength. Note the supplied DACL also only grants SY and BA,
so an administrator token (where BUILTIN\Administrators is enabled) matches it while a normal
user token does not.

This block is byte-identical in v9.5.0.0 and v10.4.0.0, so on its own it does not explain the
regression — but it is very likely why the call fails for a caller that is otherwise permitted to
write the key.

Why this matters for the original report

Together these explain the earlier observations:

no WER dump is ever produced — the process exits with code 0 rather than crashing;
the service terminates immediately (WIN32_EXIT_CODE 1067) while the same binary starts fine
when run in the foreground;
and even in the foreground the agent cannot be used as a persistent agent, because it exits
after the very first request.

Both behaviours are in the 10.4 Windows agent and are independent of the machine-to-machine
differences discussed in the original post.

Does using the ssh-agent steps in install-sshd.ps1 included in the provided zip configure the 10.4 ssh-agent service properly?
Also I'd suggest installing to C:\Program Files instead of C:\tools if possible

Thanks — the service startup issue is resolved.

The service now starts correctly

Installed to C:\Program Files\OpenSSH, ran .\install-sshd.ps1 from an elevated
console, then Start-Service ssh-agent. The agent starts, stays running, and
serves requests:

> ssh-add -l
256 SHA256:...
256 SHA256:...

No more cannot create agent root reg key, ERROR:5, no immediate exit, no
WIN32_EXIT_CODE 1067.

FYI only: foreground `-d` still exits after one request

Not a blocker for us — just noting it for completeness. Same build (10.4.0.0,
asset from 10.4.0.0p1-Preview, SHA256 B67FF8BE…), installed the same way on
two different machines, both run from an elevated console:

# machine A
agent_start pid:26280, dbg:1
client pid 18400 connected
agent_process_connection pipe:00000000000000D4
debug1: get_con_client_info: sshagent_con_username: <user>
debug1: client type: administrator
debug1: process agent request type 11          <- SSH2_AGENTC_REQUEST_IDENTITIES
debug1: iocp error: 109 on 000001D5E8D81860    <- ERROR_BROKEN_PIPE
debug1: connection 000001D5E8D81860 clean up
debug1: iocp error: 6 on 0000000000000000      <- ERROR_INVALID_HANDLE

# machine B — same shape; the agent had no identities loaded at all,
#             so this is not related to key contents
agent_start pid:5668, dbg:1
client pid 10568 connected
agent_process_connection pipe:00000000000001B8
debug1: get_con_client_info: sshagent_con_username: <user>
debug1: client type: administrator
debug1: process agent request type 11
debug1: iocp error: 109 on 0000019FA5E3F220
debug1: connection 0000019FA5E3F220 clean up
debug1: iocp error: 6 on 0000000000000000

On both machines the request is served correctly, then the process exits with
code 0 (so no WER dump), the named pipe disappears, and any subsequent
ssh-add gets No such file or directory.

-d is a debug-only path, and our actual use case — the service — works, so this
doesn't affect us in practice. Feel free to close this issue; if you'd rather
track the -d behaviour separately I'm happy to open a new one with the details
above.

Thanks again for the help — much appreciated.

FYI only: foreground -d still exits after one request

That's the intended behavior of debug mode.

Navigation Menu

Repository navigation

ssh-agent (10.4.0.0p1-Preview) fails to start on one Windows 11 26300 machine: `cannot create agent root reg key, ERROR:5` #2486

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Two-machine comparison

What has already been ruled out

The decisive oddity

Related issues

Questions

Additional observations

Environment data

Version

Visuals

Follow-up: 9.5p2 vs 10.4p1 on the same machine

9.5p2 (inbox, works) — PID 2808

10.4p1 (fails) — PID 14372

What this establishes

Interpretation

Additional finding: the foreground (`-d`) agent terminates after serving a single request

Reproduction

The same binary fails at startup when started with a MEDIUM integrity token

Why this matters for the original report

The service now starts correctly

FYI only: foreground `-d` still exits after one request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ssh-agent (10.4.0.0p1-Preview) fails to start on one Windows 11 26300 machine: cannot create agent root reg key, ERROR:5 #2486

Description

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Two-machine comparison

What has already been ruled out

The decisive oddity

Related issues

Questions

Additional observations

Environment data

Version

Visuals

Activity

github-actions commented on Nov 9, 2026

CoCooGitHub commented on Nov 9, 2026

Follow-up: 9.5p2 vs 10.4p1 on the same machine

9.5p2 (inbox, works) — PID 2808

10.4p1 (fails) — PID 14372

What this establishes

Interpretation

CoCooGitHub commented on Nov 10, 2026

Additional finding: the foreground (-d) agent terminates after serving a single request

Reproduction

The same binary fails at startup when started with a MEDIUM integrity token

Why this matters for the original report

tgauth commented on Nov 11, 2026

CoCooGitHub commented on Nov 11, 2026

The service now starts correctly

FYI only: foreground -d still exits after one request

tgauth commented on Nov 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

ssh-agent (10.4.0.0p1-Preview) fails to start on one Windows 11 26300 machine: `cannot create agent root reg key, ERROR:5` #2486

Additional finding: the foreground (`-d`) agent terminates after serving a single request

FYI only: foreground `-d` still exits after one request