After installing OpenSSH connecting to the host fails because sshd can't create the shell process running in user context

[tps800]

Prerequisites

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

Steps to reproduce

1. Install the latest OpenSSH v9.1.0.0p1-Beta from https://github.com/PowerShell/Win32-OpenSSH/releases/download/v9.1.0.0p1-Beta/OpenSSH-Win64-v9.1.0.0.msi
2. Configure sshd
3. start sshd from services
4. connect to this host with ssh @localhost
5. watch the connection succeed, but then terminate after some time without giving access to the configured shell

Expected behavior

Connect and start PowerShell.exe, pwsh.exe or cmd.exe

Actual behavior

Connection succeeds, but then terminates, because no shell could be started.

Error details

Within sshd logs you'll find lines like:

debug3: mm_request_send: entering, type 13
Accepted password for adm-sct-muc from ::1 port 56232 ssh2
debug1: monitor_child_preauth: user adm-sct-muc authenticated by privileged process
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect: entering, type 26
debug3: mm_request_receive: entering
debug3: mm_get_keystate: GOT new keys
debug3: mm_auth_password: user authenticated [preauth]
debug3: user_specific_delay: user specific delay 0.000ms [preauth]
debug3: ensure_minimum_time_since: elapsed 84665.000ms, delaying 24818.373ms (requested 6.682ms) [preauth]
debug3: send packet: type 52 [preauth]
debug3: mm_request_send: entering, type 26 [preauth]
debug3: mm_send_keystate: Finished sending state [preauth]
debug3: ReadFileEx() ERROR:109, io:000001F315A90A50
debug3: read - no more data, io:000001F315A90A50
debug3: spawning "C:\\Program Files\\OpenSSH\\sshd.exe" -dddd -z as user
CreateProcessAsUserW failed error:1314
fork of unprivileged child failed
debug1: do_cleanup

sshd fails to spawn a child within the context of the user and as this user.

### Environment data

```PowerShell
> $PSVersionTable

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

Version

v9.1.0.0p1-Beta

Visuals

No response

[PaulHigin]

This may be related to a known issue that I have seen with Windows 11, where I try to SSH localhost connect with a domain account when the machine is not domain joined. In this case I get a similar error. Local accounts always work for me. @tps800 is this the account set up you are using?

[tps800]

No. Or better: only partly. Machine and user are part of a domain. The user is in domain "A", the machine is in domain "B". The machines domain trusts the users domain, but not vice versa (the users domain does not trust the machines domain). The machine does know the user(s) from this different, but trusted domain. It is possible to query any users allowed on both domains. Local accounts are disabled by GPO on both domains. So it is impossible to test: as soon as the system is joined all local users (except those necessary) are removed.

But the same problem arose with a machine within the same domain: sshd was not able to create processes within user context, even if sshd was running within context SYSTEM. Looks like it lost at some point while starting up privileges to create processes within logging in users context. This seems to be true with or without this user logged into systems running sshd.

Within a "clean" domain, one without any GPO except those set by default by microsoft, I could not reproduce this problem. sshd is capable of creating processes within user context and the process, running within SYSTEM context, has necessary privileges.

For me it looks like some of those lockdown GPOs provided by microsoft and used by us are the cause. But it is not easy to find out which one is responsible.

[fantesykikachu]

I only get "CreateProcessAsUserW failed error:1314" and "fork of unprivileged child failed" if I change the sshd executable to always "run this program as an Administrator". However even without that the result is still the same with the connection being immediately reset.

Here are some logs:

service, privileged executable (doesn't work):

... 15924 2023-07-08 19:17:34.583 debug2: fd 4 setting O_NONBLOCK 15924 2023-07-08 19:17:34.675 debug3: spawning "\openssh\sshd.exe" -y as user 15924 2023-07-08 19:17:34.680 error: CreateProcessAsUserW failed error:740 15924 2023-07-08 19:17:34.680 fatal: privsep_preauth, fork of unprivileged child failed 15924 2023-07-08 19:17:34.680 debug1: do_cleanup 8624 2023-07-08 19:17:34.684 debug2: pselect_notify_done: reading

service, unprivileged executable (doesn't work):

... 16236 2023-07-08 18:51:55.574 debug2: fd 4 setting O_NONBLOCK 16236 2023-07-08 18:51:55.744 debug3: spawning "\openssh\sshd.exe" -y as user 16236 2023-07-08 18:51:55.748 debug2: Network child is on pid 8680 16236 2023-07-08 18:51:55.748 debug3: send_rexec_state: entering fd = 6 config len 1486 16236 2023-07-08 18:51:55.748 debug3: ssh_msg_send: type 0 16236 2023-07-08 18:51:55.748 debug3: send_rexec_state: done 16236 2023-07-08 18:51:55.748 debug3: ssh_msg_send: type 0 16236 2023-07-08 18:51:55.748 debug3: ssh_msg_send: type 0 16236 2023-07-08 18:51:55.748 debug3: preauth child monitor started 16236 2023-07-08 18:51:55.752 debug1: monitor_read_log: child log fd closed 16236 2023-07-08 18:51:55.752 debug3: mm_request_receive: entering 16236 2023-07-08 18:51:55.752 debug1: do_cleanup 16236 2023-07-08 18:51:55.752 debug1: Killing privsep child 8680 12252 2023-07-08 18:51:55.762 debug2: pselect_notify_done: reading

elevated Command Prompt (works):

... 8116 2023-07-08 19:33:34.055 debug2: fd 4 setting O_NONBLOCK 8116 2023-07-08 19:33:34.055 debug3: spawning "\openssh\sshd.exe" -y as user 8116 2023-07-08 19:33:34.060 debug2: Network child is on pid 11360 8116 2023-07-08 19:33:34.060 debug3: send_rexec_state: entering fd = 6 config len 1486 8116 2023-07-08 19:33:34.060 debug3: ssh_msg_send: type 0 8116 2023-07-08 19:33:34.060 debug3: send_rexec_state: done 8116 2023-07-08 19:33:34.060 debug3: ssh_msg_send: type 0 8116 2023-07-08 19:33:34.060 debug3: ssh_msg_send: type 0 8116 2023-07-08 19:33:34.060 debug3: preauth child monitor started 11360 2023-07-08 19:33:34.074 debug3: process_channel_timeouts: setting 0 timeouts 11360 2023-07-08 19:33:34.074 debug3: channel_clear_timeouts: clearing 11360 2023-07-08 19:33:34.074 debug3: recv_idexch_state: entering fd = 3 11360 2023-07-08 19:33:34.074 debug3: ssh_msg_recv entering 11360 2023-07-08 19:33:34.074 debug3: recv_idexch_state: done 11360 2023-07-08 19:33:34.074 debug2: fd 5 setting O_NONBLOCK ...

The main difference between the elevated Command Prompt (which works) and the unprivileged service (which doesn't), is the working one is preventing timeouts.