You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am wondering if we could hear about the design effort to ensure that users logging on through SSH have most of the same things we'd expect when logging in via Winrm?
For instance, winrm does not allow the logon of users who aren't formally created on the system - but on one release I believe SSHD was allowing a logon if the authorized_keys file existed - regardless of whether the "user" was a full on windows user. In #645, environment variables seem to be an issue.
I'm unsure how the move to remove ssh-lsa.dll may have changed what an "ssh user" looks like upon logon? Does the new solution require users logging in to be full, formally created windows users?
Does the process of logging on trigger the "first time local profile creation" of Windows when the user id is valid, but they have never logged on to the machine before?
If the concept of an "ssh user" is not currently targeted to be identical to the normal Windows expectations of what a "user" is and what needs to be done to properly initiate one under Windows - it seems like it will have continuous, fundamental, slowly discovered, (but significant) limiting differences.
If it has to be that the concepts are not synonymous - then a "current design" document would help everyone know what they are getting into if they decide to commit whole heartedly to something like "ssh based remoting for all their machines".
The text was updated successfully, but these errors were encountered:
Thanks @DarwinJS. I'll add the following details to the design doc on Wiki.
Remote ssh sessions run under the context of the client user. Client authentication, be it password or key-based, results in the generation of a user token using which the remote session process is spawned. This means that in order to login via ssh, one needs to have a valid Windows account on the target.
ssh-lsa.dll removal is unrelated and should have no impact on the what's detailed above.
If user profile does not exist, it gets created upon first logon via ssh. This would typically (in default sshd configuration) be via password based authentication (since profile does not exist for authorized_keys to be placed). There is related issue with user getting logged into %windir% upon first logon (though the profile gets loaded). This is tracked as #478 that will be fixed soon.
WinRM Vs SSH - there should be no difference in the user capabilities within the remote session.
I am wondering if we could hear about the design effort to ensure that users logging on through SSH have most of the same things we'd expect when logging in via Winrm?
For instance, winrm does not allow the logon of users who aren't formally created on the system - but on one release I believe SSHD was allowing a logon if the authorized_keys file existed - regardless of whether the "user" was a full on windows user. In #645, environment variables seem to be an issue.
I'm unsure how the move to remove ssh-lsa.dll may have changed what an "ssh user" looks like upon logon? Does the new solution require users logging in to be full, formally created windows users?
Does the process of logging on trigger the "first time local profile creation" of Windows when the user id is valid, but they have never logged on to the machine before?
If the concept of an "ssh user" is not currently targeted to be identical to the normal Windows expectations of what a "user" is and what needs to be done to properly initiate one under Windows - it seems like it will have continuous, fundamental, slowly discovered, (but significant) limiting differences.
If it has to be that the concepts are not synonymous - then a "current design" document would help everyone know what they are getting into if they decide to commit whole heartedly to something like "ssh based remoting for all their machines".
The text was updated successfully, but these errors were encountered: