Dear Danny, thanks for helping.

Short answer: use this install script - https://github.com/PowerShell/openssh-portable/blob/latestw_all/contrib/win32/openssh/install-sshd.ps1

Here is the rest of the diagnostics of this problem, in case it is helpful to anyone.

One observation I failed to mention: other keys load apparently without error.
I run sshd, either manually or through the net start options, from an Admin Powershell.
I noticed that, on the machine it fails, the rsa key has other mode attributes than on the machine where it doesn't fail:

 Get-Item -path .\ssh_host_rsa_key

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-ar---        07/08/2023     16:08           2610 ssh_host_rsa_key

note the 'read' mode - versus, where it does work:

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        30/11/2023     09:57           2622 ssh_host_rsa_key

I found out about the Get-Acl command to display owner information. I get, in windows 11 (where it doesn't work):

Path   : Microsoft.PowerShell.Core\FileSystem::C:\ProgramData\ssh\ssh_host_rsa_key
Owner  : AUTORIDADE NT\SISTEMA
Group  : [Computer name]\None
Access :
Audit  :
Sddl   : [...] 

while where it does work it is like this:

Path   : Microsoft.PowerShell.Core\FileSystem::C:\ProgramData\ssh\ssh_host_rsa_key
Owner  : AUTORIDADE NT\SISTEMA
Group  : AUTORIDADE NT\SISTEMA
Access : AUTORIDADE NT\SISTEMA Allow  FullControl
         BUILTIN\Administradores Allow  FullControl
Audit  :
Sddl   :  [...]

I have a similar profile with the host key files that do not raise an error on my Windows 11 installation. AUTORIDADE NT is NT Authority in english-language versions of Windows.

This clearly suggests that the system identifier of the ssh_host_rsa_key is wrong, and that the script to fix host keys that maybe should detect this, doesn't:

[*] C:\ProgramData\ssh\ssh_host_rsa_key
      looks good

After running the install-sshd.ps1 script that was linked from the thread you referred to, a number of file permissions changed. user access to the logs and the public keys was removed, and access to the rsa key was changed:

  [*] C:\ProgramData\ssh\ssh_host_rsa_key
'AUTORIDADE NT\SISTEMA' now has FullControl to 'C:\ProgramData\ssh\ssh_host_rsa_key'.
'BUILTIN\Administradores' now has FullControl to 'C:\ProgramData\ssh\ssh_host_rsa_key'.
      Repaired permissions

Now I have:

PS C:\ProgramData\ssh> Get-Acl .\ssh_host_rsa_key |Format-List


Path   : Microsoft.PowerShell.Core\FileSystem::C:\ProgramData\ssh\ssh_host_rsa_key
Owner  : AUTORIDADE NT\SISTEMA
Group  : [computer name]\None
Access : AUTORIDADE NT\SISTEMA Allow  FullControl
         BUILTIN\Administradores Allow  FullControl
Audit  :
Sddl   :  [...]

The Group did not change, but Acess did. I have no problem anymore with the rsa key when starting the service manually. "net start sshd" and 'Start-Service -Name "sshd"' seem to run without issues now. I tested the connection through localhost and from outside the server.

It works!

Thank you very much!

I think the install script should be mentioned on the OpenSSH installation pages.

Thank you very much.

My problem was slightly different: I logged on as administrator, created a new file that contained a host key, set the correct permissions on that file (administrator and system full access each, nothing else), and told sshd.exe to use that host key file via config file (HostKey directive). That is, I wanted to use a host key file with a name that differs from the default host key file name. Then I tried to start the OpenSSH service.

My next action was to scratch my head for quite some time. If I removed the HostKey directive from sshd_config, the service started, and if I added it back, the service failed to start. I was sure that I had the correct permissions on that file, though.

It finally turned out that not only the correct permissions, but also the correct owner must be set on that file. Once I had changed the owner from "administrator" to "SYSTEM", the service started without further issues. In my case, I have identified the problem by comparing the permissions and the owner of the new file with the permissions and the owner of the default host key files.

For those who don't like the command line: You can also do that using the GUI.