ssh-agent either autostart by default or allow user session mode as on other platforms

[agowa]

Summary of the new feature / enhancement

Hi,

please allow ssh-agent to either work in user-session mode (as on all other platforms) or make the ssh-agent windows service autostart by default (or set the default ACLs of it to allow all authenticated users to start it, if you despise a user-session mode version that much :p ). Always when you request openssh to be enabled by the IT department they forget to set the ssh-agent to autostart as they assume just installing the windows feature for openssh is enough. Also almost everyone I talked about this either didn't know they had to do it or declined it for security reasons often quoting that it isn't required on linux so they won't do it on windows either as they don't know its impact (or do not want to have to deal with the risk for privilege elevation through a 0-day).

So could you please allow ssh-agent to work when invoked by a user without administrative permissions out of the box (aka. without the service being having to be manually edited to autostart, or to be start-able by regular users)?

Currently all a user ever sees in these cases is this error when trying to start/use ssh-agent.exe themselves (as they'd do on any other platform if it is not already running):

unable to start ssh-agent service, error :1058

Acknowledgement
I can see how from a design standpoint "outsourcing" the ssh-agent services sensitive parts to a system service that runs outside of the users security context increases security (similar to lsass) however this should never break the commonly established way of using it without such a privilege service. Especially because it doesn't reduce the attack surface but merely shifts it from "extracting secrets from ssh-agent memory" to a "potential privilege escalation to system"...
And by that it also breaks common assumptions in security and risk assessments of being isolated to a single session without any possibility for local privilege escalation. It is commonly assumed that a compromised ssh-agent cannot cause a compromise to the entire system and at worst (including potential 0-day vulnerabilities) will only leak the affected users secrets and only the current users secrets. The current implementation with the windows service breaks this assumption (this is probably also why the windows service is not set to autostart by default already) without any way to fall back on the original (and expected) behaviour of running within (each) users session. As windows (by now) also has user-services those could also be an option. Because of this security trade off both versions should be available to choose from (mainly because the windows service one now already exists, otherwise I would advocate for only the per-session and already established way).

Proposed technical implementation details (optional)

Either:

1. Make the ssh-agent windows service autostart by default and ship via windows updates for all versions containing OpenSSH, so that it "just works" after enabling/installing OpenSSH in Windows.
2. Change the default ACLs of the current ssh-agent windows service to allow it being started by any authenticated users. Same effect as a but would avoid it being running without ever being used (aka. make it start "on-demand" by default).
3. Change ssh-agent into an per-user service instead of a system-service (best case they provide a similar isolation for storing the secrets, where it could replace the current implementation and worst case it provides similar security assumptions as on linux and is an alternative for where the windows service is not desired.)
4. allow ssh-agent to run without this service as on all other platforms to allow for the same risk management and have the same attack-surface in worst (0-day) case scenarios. And for the risk being mitigated the same way.
5. Use the internals also the "work profile" uses (I don't know too much about it, as I'm only confronted with it as a user and not as a dev or admin myself), however that feature shows the potential for having a security barrier within a single user session. So maybe some of the internals of it could be reused in some way? - see "Connect a Work or School Account" within the Manage user accounts in Windows docs

I'd suggest implementing solution 4 and one of 1, 2, or 3. Because 4 is the established way on all other platforms and has security benefits (in regards to mitigating against privilege escalation 0-days) and therefore should always be an option (even though it would only be used if the shs-agent windows system service is not started). As the key is provided by the user and therefore already exposed to everything within the users session anyway a potential malicious "mode switch" to user-session mode (or regular "normal user process") does not have to be mitigated. Even in the case of it being provided by e.g. KeePassXC the source would still be a user-process. The handling of smartcards (and security keys u2f/fido) is however still debatable, for this I'd suggest to rely on the windows ACLs on the underlaying device. If the user has access to the device then there is also no point to not allowing the ssh-agent running within the users session to use it. And if they do not, well then that problem is already solved by not being able to access the device...