Skip to content

Design Document on how SSHD Handles "Users" as an entity #695

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DarwinJS opened this issue Apr 28, 2017 · 2 comments
Closed

Design Document on how SSHD Handles "Users" as an entity #695

DarwinJS opened this issue Apr 28, 2017 · 2 comments

Comments

@DarwinJS
Copy link

DarwinJS commented Apr 28, 2017

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".

@manojampalam
Copy link
Contributor

manojampalam commented Apr 28, 2017

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.

#645 is an unrelated issue.

@DarwinJS
Copy link
Author

@manojampalam - excellent - exactly what I was asking about. Might be nice to put that in the documents somewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants