Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
- Date: Mon, 29 May 2017 19:14:30 +0200
- From: Houder <houder@xxxxxxxxx>
- Subject: Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 2017-05-29 11:48, Houder wrote:
On 2017-05-29 10:39, Marco Atzeri wrote:
On 29/05/2017 07:23, Houder wrote:
... because, that is, I think, what I am seeing:
- the userid of child sshd is still 'cyg_server' ...
- and I get an elevated shell when I login ...
Not what I expected ...
please read the last Announcement
It seems you misunderstood the communication:
- the possibility to NOT use "privilege separation" is deprecated
- "privilege separation" will became mandatory
Sorry for the misunderstanding. Yes, to my knowledge, PS, privilege
separation, is now mandatory (using a new mechanism under Linux ).
Because of PS, I expect to see an UNprivileged sshd process talking
to the user process (where the ssh command has been executed).
But above all, I expect an UNelevated shell when I login in ...
However, what I get after login (after providing my credentials) is
an ELEVATED shell (yes, Administrators is part of the group set).
Now I wonder if this happens because I do NOT observe PS.
Look below, please ... After executing the ssh command, ssh asks for
my credentials ... in stead of providing my credentials, I execute
the ps command in a second terminal. To my surprise, the grandchild
of the listener is executed using "cyg_server" and not "sshd" ...
Currently, I am looking at:
... and read it MULTIPLE times! (and tried, well, about anything)
However, I found a clue here:
(Re: admin privileges when logging in by ssh? -- by Corinna)
The thread starts here:
(admin privileges when logging in by ssh? -- by Andrew Schulman)
Above Corinna writes:
"In all cases, password auth and passwordless auth, you should get a
admin token. In case of password auth and in the passwordless methods
2 and 3, the OS returns a restricted token under UAC, but ...
that token has a _reference_ to the full admin token attached.
fetches this token and uses that when switching the user context.
The account (Henri) from which I executed the ssh command, is - yes, I
forgot to tell - , a privileged account ...
However when I login to that account, it "normally" starts an UNelevated
shell ... Not so if one executes the ssh command ... apparently.
And that is a bit of a SURPRISE ... to say the least !!!!!
Even more surprising is when I execute the ssh command from an account
that is NOT privileged (using another account, named jvdwater).
- yes. this time I get an UNelevated shell (using ssh)
- however, the userid of the grandchild of the sshd listener, is STILL
cyg_server ... NOT sshd!
As if the "sshd" account is NEVER, NEVER used during the _whole_ process
(that is, there is NO privilege separation, as far as I can tell).
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple