[e12e]

The more things change..., from:

https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3...

"If you need key-based authentication:

Install key-auth package

run setup-ssh-lsa.cmd

reboot"

Reboot?

And this gem: "SSH daemon needs to run as System to support key-based authentication".

Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys are particularly sensitive (certainly much less sensitive than being able to check passwords for validity)?

[kohenkatz]

Have you checked what user OpenSSH usually runs as on a linux machine in order to allow key-based authentication? I'll give you a hint: it's root. That's no different than running as SYSTEM on Windows.

[e12e]

As a sibling comment mentioned, it makes perfect sense that the ability to create a user session requires a certain privilege. What struck me as odd, was that it only needed this on Windows when using key-based authentication - not when allowing password-based login.

AFAIK ssh needs access to /etc/shadow on Linux, if you want to use system passwords. But also, AFAIK, nothing stops you from running ssh in a chroot, without any such access (well, access to a /etc/shadow under the chroot probably).

[Asmod4n]

Regarding System User: https://github.com/PowerShell/Win32-OpenSSH/issues/2, it needs that right to generate user tokens

[e12e]

Thank you for that. It makes a certain kind of sense, that impersonating a user/creating user sessions requires a high privilege. I think I'd still be more happy with it running as a low privilege user allowing log-in as "nobody"/"guest" and then elevating to a user with login/pw via "runas" or equivalent.

I can see how the only way to login directly to a certain user id would either require ssh to run as that user id or as System.

[switch007]

That is the crux of it. Windows is not going to fundamentally change its authentication system to work around SSH. It's going to feel "hacky" compared to SSH on *NIX (also console interactivity). You'll still need to run Windows updates as a scheduled task as the system user because remote connections have a remote token and the Window Update API blocks such connections...