Cannot connect as "NT authority\system" account

[fpopineau]

trafficstars

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

I am using OpenSSH 8.6.0p1 on Windows 11 (client) and on Windows Server Essentials 2019 (server) I can connect from client to server with any account except "NT authority\server" Normal user accounts do work perfectly. Open a powershell terminal as System account :

Start-Process -FilePath cmd.exe -Verb Runas -ArgumentList '/k C:\Local\Sysinternals\PsExec.exe -i -s powershell.exe'

(using psexec from SysInternals) then try to connect to the server:

sftp 192.168.0.36

Expected behavior

The connection should be working. Or it should state that it is not possible to connect as SYSTEM.

Actual behavior

The connection is closed :

PS C:\WINDOWS\system32\config\systemprofile> sftp 192.168.0.36
Connection reset by 192.168.0.36 port 22
Connection closed

### Error details

```console
The log file for sshd reports:

8392 2023-04-11 00:06:19.468 debug3: checking match for 'Group Administrateurs' user système host 192.168.0.35 addr 192.168.0.35 laddr 192.168.0.36 lport 22
8392 2023-04-11 00:06:19.469 debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'syst�me' Status: 0xC000006D SubStatus 0.
8392 2023-04-11 00:06:19.469 debug3: get_user_token - unable to generate token for user syst�me
8392 2023-04-11 00:06:24.216 debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'syst�me' Status: 0xC000006D SubStatus 0.
8392 2023-04-11 00:06:24.216 error: get_user_token - unable to generate token on 2nd attempt for user syst�me
8392 2023-04-11 00:06:24.216 fatal: ga_init, unable to resolve user système
8392 2023-04-11 00:06:24.216 debug1: do_cleanup
8392 2023-04-11 00:06:24.216 debug1: Killing privsep child 1560

Environment data

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

Version

8.6.0p1

Visuals

No response

[jborean93]

Why would you expect to be able to connect as SYSTEM, this is a privileged account builtin to the OS itself and is not designed as an account you can log on with remotely. You will need to specify a different username when connecting to the host like sftp [email protected].

[fpopineau]

Why would you expect to be able to connect as SYSTEM, this is a privileged account builtin to the OS itself and is not designed as an account you can log on with remotely. You will need to specify a different username when connecting to the host like sftp [email protected].

There is nothing that prevents it. This would be the normal way for restic to do backups. And it worked at some point (with 8.1.0 ?).

[jborean93]

I would argue that it supporting SYSTEM in older versions was unintended and it not working anymore was either done as an intentional change and if it was not it should not be reverted back. If restic is relying on this behaviour it should definitely change how it works.

[fpopineau]

Then I would argue that it shows that nothing prevents it from being used this way :-) I don't take "privileged account" as a reason for not connecting with this account if the permissions are right. Maybe I should (?) Actually restic does not require it. However I have a backup scheduled task that is running as System. Trying to test it, I checked if I could sftp to the server as System, and I couldn't. The backup themselves use the account of the user to backup, so that is not a huge problem (except if we want to backup the whole system ?)

[mgkuhn]

Just curious: how would login authentication for SYSTEM work? Where is the userprofile and therefore .ssh/authorized_keys of SYSTEM located, needed for publickey authentication? How does one give SYSTEM a password, needed for password authentication? (GSSAPI authentication certainly is out of the question, I'd hope, as it is not a domain account.)

[fpopineau]

I don't remember precisely what I traced at the time I was looking into this, but I would say PROGRAMDATA/ssh/administrators_authorized_keys and that was not what was blocking. But all in, all it is probably better that this connection as NT Authority\SYSTEM does not work.

-- Fabrice

Le mer. 16 août 2023 à 18:02, Markus Kuhn @.***> a écrit :

Just curious: how would login authentication work for SYSTEM work? Where is the userprofile and therefore .ssh/authorized_keys of SYSTEM located, needed for publickey authentication? How does one give SYSTEM a password, needed for password authentication? (GSSAPI authentication certainly is out of the question, I'd hope, as it is not a domain account.)

— Reply to this email directly, view it on GitHub https://github.com/PowerShell/Win32-OpenSSH/issues/2048#issuecomment-1680883617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOTV37VXQX4W24BUAR7MLTXVTVLHANCNFSM6AAAAAAWPCRISY . You are receiving this because you authored the thread.Message ID: @.***>

[BasedUser]

I apologize for necromancing/peanutposting this issue, but using external programs as a workaround is still a viable option. Example config (with PsExec, or just run the command directly):

Match User Administrator
    ForceCommand PsExec -accepteula -nobanner -s -h cmd

However, if you use PsExec specifically be prepared to lose the TTY-ness of your SSH session. No tab-complete, etc.

If for some reason you want to separate SYSTEM and Administrator, though, tough luck. Connection resets don't occur when trying to connect as other ntauthority accounts (LOCAL SERVICE, NETWORK SERVICE).