Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 05/31/2017 05:37 AM, Houder wrote: On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote: [snip] Cygwin's link to the Windows user ID is through the UID/SID mapping. In your case, you're apparently using /etc/passwd and so that's where the mapping happens. You can map the UID of a Cygwin user to any valid Windows SID by editing the SID as you did. This doesn't change how things look in the Cygwin environment (i.e. the UID and user name are still the same) but it does make a difference to Windows. So the fact that you can change the SID for the 'sshd' user and still get it to run is not all that surprising, assuming that the new Windows SID that you're using as 'sshd' now has at least similar permissions. Of course, if you remove Cygwin's understanding of 'sshd' so that it can't do the mapping of UID to SID or even have a valid UID, then subsequent problems are not unexpected. Hi Larry, Thanks for your reply! Discussion! First of all, I do not pretend to know Windows ... neither do I pretend that I know more about ssh/Cygwin than Corinna does (basically, I know not very much). .. the only thing I am able to, is "observe" (and I may interpret wrong), and may have done "stupid" things. That is why your reply is appreciated by me. Now back to your reply: I had modified /etc/password as follows: (note the in the sid) sshd:*:1015:513:U-Seven\sshd,S-1-5-21-91509220-1575020443-2714799223-:/var/empty:/bin/false However, just now I modified it as follows: sshd:*:1015:513:U-Seven\sshd,S-1-5-21--xx-xx-:/var/empty:/bin/false (again changed the sshd service into 'automatic'), and rebooted the system. After system reboot, an elevated shell is started ... (the ampersand sign at the end of the prompt indicates it is an elevated shell) # my .bash_profile interrogates the cygwin1.dll ... /home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc 64-@@# 64-@@# cygrunsrv -Q sshd Service : sshd Display name: CYGWIN sshd Current State : Running Controls Accepted : Stop Command : /usr/sbin/sshd -4 -D -e Looking good ... 64-@@# net user sshd The user name could not be found. More help is available by typing NET HELPMSG 2221. As far as I know, this means that Windows tells me user sshd does NOT exist! However, I can still use the ssh command ... (see below). Now, if I understand correctly, "Corinna" may use the first (of the 4) method, i.e. the one based on NtCreateToken(), to change the user context ... (Q: is that even possible for a NON-existing user?) However, neither the ps command nor the "Process Explorer" show me a context that "belongs" to user sshd [1] (in stead it belongs to user cyg_server). [1] I refer to the grandchild of the listener, the one that exists before the authentication phase terminates ... Yes, I know; I may still be wrong ... I report what I observe ... yes, I do not have the deep knowledge of Windows that Corinna has. I know. Regards, Henri - From an UNelevated shell: 64-@@ ssh -p -l Henri 192.168.178.15 Enter passphrase for key '/home/Henri/.ssh/': # Henri is privileged Last login: Wed May 31 10:30:52 2017 from 192.168.178.15 TADA ! < contents of /etc/motd /home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc 64-@@# exit < full-blown elevated shell! (try whoami /all) logout Connection to 192.168.178.15 closed. 64-@@ ssh -p -l jvdwater 192.168.178.15 jvdwater@192.168.178.15's password: # jvdwater is UNprivileged Last login: Wed May 31 10:29:27 2017 from 192.168.178.15 TADA ! 64-@@ exit < ordinary UNelevated shell logout Connection to 192.168.178.15 closed. 64-@@# tail -f /var/log/sshd.log Server listening on 0.0.0.0 port . Accepted publickey for Henri from 192.168.178.15 port 49186 ssh2: Received disconnect from 192.168.178.15 port 49186:11: disconnected by user Disconnected from user Henri 192.168.178.15 port 49186 Accepted password for jvdwater from 192.168.178.15 port 49191 ssh2 Received disconnect from 192.168.178.15 port 49191:11: disconnected by user Disconnected from user jvdwater 192.168.178.15 port 49191 I'm replying directly to your original replies to me but this shouldn't indicate to anyone that subsequent discussion by others hasn't provided good and useful information. My reply more directly addresses your email though so I wanted to reference it without those intervening discussions to hopefully avoid confusion. At the moment, the only system I have access to that has Cygwin's SSH set up on it is one that's using AD and there when I login using public key or password authentication, I'm always logged in as my user without elevated privileges. I'm not going to speculate about whether this is indicative of proper operation or not for this environment. I just offer it as another observation. That said, I will offer one speculation (because I
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
Greetings, Houder!
> Anyone out there, who uses AD, in stead of /etc/{passwd,group},
Nobody here uses "/etc/{passwd,group}" anymore, except for very special cases.
This is not related to AD.
--
With best regards,
Andrey Repin
Wednesday, May 31, 2017 23:14:34
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 5/31/2017 12:34 PM, Houder wrote:
> On Wed, 31 May 2017 10:59:38, cyg Simple wrote:
>> On 5/31/2017 10:16 AM, Houder wrote:
>>> On Wed, 31 May 2017 09:27:02, cyg Simple wrote:
>>>
>>> [snip]
All of this talk of /etc/passwd leads me to point you to
https://cygwin.com/cygwin-ug-net/ntsec.html.
>>>
>>> cyg,
>>>
>>> Do you want me to study that text a second, third, fourth or Xth time ...?
>>>
>>
>> Yes, especially section
>> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping where it
>> explains that /etc/passwd and /etc/group are now deprecated and it's use
>> is for backward compatibility and that you should be using
>> /etc/nsswitch.conf[1] instead. Have you attempted this?
>>
>> [1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
>
> Actually, that text reads:
>
> = Mapping Windows SIDs to POSIX uid/gid values:
>
> * Read /etc/passwd and /etc/group files if they exist, just as in the olden
> days, mainly for backward compatibility.
> -
>
> It does not stipulate that these files are no longer supported ... Corinna did
> not dare to proclaim them "deprecated".
>
> Do I use the file /etc/nsswitch.conf? Yes, certainly. As shown in:
>
> https://cygwin.com/ml/cygwin/2017-05/msg00456.html
> (see bottom of post)
>
> Do you want me to drop /etc/{passwd,group} files. Yes, you do. I will not.
>
That choice is yours but they are needless except for very limited needs.
> Moreover, it is completely irrelevant from a logical point of view whether
> /etc/{passwd,group) or AD is used to maintain the "network administration".
>
So what. You have to maintain separate multiple databases for the same
user.
Just give removing these two files a try to see if you have good success.
--
cyg Simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On Wed, 31 May 2017 10:59:38, cyg Simple wrote:
> On 5/31/2017 10:16 AM, Houder wrote:
> > On Wed, 31 May 2017 09:27:02, cyg Simple wrote:
> >
> > [snip]
> >> All of this talk of /etc/passwd leads me to point you to
> >> https://cygwin.com/cygwin-ug-net/ntsec.html.
> >
> > cyg,
> >
> > Do you want me to study that text a second, third, fourth or Xth time ...?
> >
>
> Yes, especially section
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping where it
> explains that /etc/passwd and /etc/group are now deprecated and it's use
> is for backward compatibility and that you should be using
> /etc/nsswitch.conf[1] instead. Have you attempted this?
>
> [1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
Actually, that text reads:
= Mapping Windows SIDs to POSIX uid/gid values:
* Read /etc/passwd and /etc/group files if they exist, just as in the olden
days, mainly for backward compatibility.
-
It does not stipulate that these files are no longer supported ... Corinna did
not dare to proclaim them "deprecated".
Do I use the file /etc/nsswitch.conf? Yes, certainly. As shown in:
https://cygwin.com/ml/cygwin/2017-05/msg00456.html
(see bottom of post)
Do you want me to drop /etc/{passwd,group} files. Yes, you do. I will not.
Moreover, it is completely irrelevant from a logical point of view whether
/etc/{passwd,group) or AD is used to maintain the "network administration".
Regards,
Henri
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 5/31/2017 10:16 AM, Houder wrote: > On Wed, 31 May 2017 09:27:02, cyg Simple wrote: > > [snip] >> All of this talk of /etc/passwd leads me to point you to >> https://cygwin.com/cygwin-ug-net/ntsec.html. > > cyg, > > Do you want me to study that text a second, third, fourth or Xth time ...? > Yes, especially section https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping where it explains that /etc/passwd and /etc/group are now deprecated and it's use is for backward compatibility and that you should be using /etc/nsswitch.conf[1] instead. Have you attempted this? [1] https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE! -- minor correction
On Wed, 31 May 2017 16:16:38, Houder wrote:
[snip]
> Anyone out there, who uses AD, in stead of /etc/{passwd,group}, and is brave
> enough to delete the sshd account? Is ssh still working?
i.e. NOT from AD, but delete as an account (net user sshd /delete).
Regards,
Henri
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On Wed, 31 May 2017 09:27:02, cyg Simple wrote:
[snip]
> All of this talk of /etc/passwd leads me to point you to
> https://cygwin.com/cygwin-ug-net/ntsec.html.
cyg,
Do you want me to study that text a second, third, fourth or Xth time ...?
However, let me take another angle now ...
Active Directory is just Microsoft's version of the 'network database', a way
to keep housekeeping in a centralized manner (like NIS).
Agreed?
Anyone out there, who uses AD, in stead of /etc/{passwd,group}, and observes
that the grandchild of the listener is executed by user "sshd"?
Anyone out there, who uses AD, in stead of /etc/{passwd,group}, and is brave
enough to delete the sshd account? Is ssh still working?
Now you might say that I am "a bit aggressive" above (yes, I _do_ feel a bit
peevish). However I would like to see arguments that stick and/or proof that
shows me wrong.
Larry Hall replied with an argument, you did not (neither did Andrey Repin).
Regards,
Henri
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 5/31/2017 5:37 AM, Houder wrote: > On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote: > > [snip] >> Cygwin's link to the Windows user ID is through the UID/SID mapping. In >> your case, you're apparently using /etc/passwd and so that's where the >> mapping happens. You can map the UID of a Cygwin user to any valid Windows >> SID by editing the SID as you did. This doesn't change how things look in >> the Cygwin environment (i.e. the UID and user name are still the same) but >> it does make a difference to Windows. So the fact that you can change the >> SID for the 'sshd' user and still get it to run is not all that surprising, >> assuming that the new Windows SID that you're using as 'sshd' now has at >> least similar permissions. Of course, if you remove Cygwin's understanding >> of 'sshd' so that it can't do the mapping of UID to SID or even have a >> valid UID, then subsequent problems are not unexpected. > > Hi Larry, > > Thanks for your reply! Discussion! > > First of all, I do not pretend to know Windows ... neither do I pretend that I > know more about ssh/Cygwin than Corinna does (basically, I know not very > much). > > .. the only thing I am able to, is "observe" (and I may interpret wrong), and > may have done "stupid" things. That is why your reply is appreciated by me. > > Now back to your reply: > > I had modified /etc/password as follows: (note the in the sid) > > sshd:*:1015:513:U-Seven\sshd,S-1-5-21-91509220-1575020443-2714799223-:/var/empty:/bin/false > > However, just now I modified it as follows: > > sshd:*:1015:513:U-Seven\sshd,S-1-5-21--xx-xx-:/var/empty:/bin/false > > (again changed the sshd service into 'automatic'), and rebooted the system. > > After system reboot, an elevated shell is started ... > (the ampersand sign at the end of the prompt indicates it is an elevated > shell) All of this talk of /etc/passwd leads me to point you to https://cygwin.com/cygwin-ug-net/ntsec.html. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote: [snip] > Cygwin's link to the Windows user ID is through the UID/SID mapping. In > your case, you're apparently using /etc/passwd and so that's where the > mapping happens. You can map the UID of a Cygwin user to any valid Windows > SID by editing the SID as you did. This doesn't change how things look in > the Cygwin environment (i.e. the UID and user name are still the same) but > it does make a difference to Windows. So the fact that you can change the > SID for the 'sshd' user and still get it to run is not all that surprising, > assuming that the new Windows SID that you're using as 'sshd' now has at > least similar permissions. Of course, if you remove Cygwin's understanding > of 'sshd' so that it can't do the mapping of UID to SID or even have a > valid UID, then subsequent problems are not unexpected. Hi Larry, Thanks for your reply! Discussion! First of all, I do not pretend to know Windows ... neither do I pretend that I know more about ssh/Cygwin than Corinna does (basically, I know not very much). .. the only thing I am able to, is "observe" (and I may interpret wrong), and may have done "stupid" things. That is why your reply is appreciated by me. Now back to your reply: I had modified /etc/password as follows: (note the in the sid) sshd:*:1015:513:U-Seven\sshd,S-1-5-21-91509220-1575020443-2714799223-:/var/empty:/bin/false However, just now I modified it as follows: sshd:*:1015:513:U-Seven\sshd,S-1-5-21--xx-xx-:/var/empty:/bin/false (again changed the sshd service into 'automatic'), and rebooted the system. After system reboot, an elevated shell is started ... (the ampersand sign at the end of the prompt indicates it is an elevated shell) # my .bash_profile interrogates the cygwin1.dll ... /home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc 64-@@# 64-@@# cygrunsrv -Q sshd Service : sshd Display name: CYGWIN sshd Current State : Running Controls Accepted : Stop Command : /usr/sbin/sshd -4 -D -e Looking good ... 64-@@# net user sshd The user name could not be found. More help is available by typing NET HELPMSG 2221. As far as I know, this means that Windows tells me user sshd does NOT exist! However, I can still use the ssh command ... (see below). Now, if I understand correctly, "Corinna" may use the first (of the 4) method, i.e. the one based on NtCreateToken(), to change the user context ... (Q: is that even possible for a NON-existing user?) However, neither the ps command nor the "Process Explorer" show me a context that "belongs" to user sshd [1] (in stead it belongs to user cyg_server). [1] I refer to the grandchild of the listener, the one that exists before the authentication phase terminates ... Yes, I know; I may still be wrong ... I report what I observe ... yes, I do not have the deep knowledge of Windows that Corinna has. I know. Regards, Henri - >From an UNelevated shell: 64-@@ ssh -p -l Henri 192.168.178.15 Enter passphrase for key '/home/Henri/.ssh/': # Henri is privileged Last login: Wed May 31 10:30:52 2017 from 192.168.178.15 TADA ! < contents of /etc/motd /home/corinna/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/cygheap.cc 64-@@# exit < full-blown elevated shell! (try whoami /all) logout Connection to 192.168.178.15 closed. 64-@@ ssh -p -l jvdwater 192.168.178.15 jvdwater@192.168.178.15's password: # jvdwater is UNprivileged Last login: Wed May 31 10:29:27 2017 from 192.168.178.15 TADA ! 64-@@ exit < ordinary UNelevated shell logout Connection to 192.168.178.15 closed. 64-@@# tail -f /var/log/sshd.log Server listening on 0.0.0.0 port . Accepted publickey for Henri from 192.168.178.15 port 49186 ssh2: Received disconnect from 192.168.178.15 port 49186:11: disconnected by user Disconnected from user Henri 192.168.178.15 port 49186 Accepted password for jvdwater from 192.168.178.15 port 49191 ssh2 Received disconnect from 192.168.178.15 port 49191:11: disconnected by user Disconnected from user jvdwater 192.168.178.15 port 49191 = -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 05/30/2017 09:50 AM, Houder wrote: On Mon, 29 May 2017 19:14:30, Houder wrote: [snip] 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). .. wanted to share this experience with you. - deleted user/account 'sshd' # net user sshd /delete - modified the last part (rid?) of the sid belonging to user/account 'sshd' in (in /etc/passwd) - rebooted Before reboot, I changed 'sshd' in an automatic service (was: manual) After the system had rebooted: - 'cygrunsrv -Q sshd' shows 'sshd' running ... - 'tail -f /var/log/sshd.log' shows 'sshd' listening ... - 'net user' shows user/account 'sshd' gone ... I can still use ssh ... (both password authentication and key authentication) Yes, if I remove user/account 'sshd' completely from /etc/passwd, only then 'sshd' won't start ... Cygwin's link to the Windows user ID is through the UID/SID mapping. In your case, you're apparently using /etc/passwd and so that's where the mapping happens. You can map the UID of a Cygwin user to any valid Windows SID by editing the SID as you did. This doesn't change how things look in the Cygwin environment (i.e. the UID and user name are still the same) but it does make a difference to Windows. So the fact that you can change the SID for the 'sshd' user and still get it to run is not all that surprising, assuming that the new Windows SID that you're using as 'sshd' now has at least similar permissions. Of course, if you remove Cygwin's understanding of 'sshd' so that it can't do the mapping of UID to SID or even have a valid UID, then subsequent problems are not unexpected. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On Mon, 29 May 2017 19:14:30, Houder wrote: [snip] > 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). .. wanted to share this experience with you. - deleted user/account 'sshd' # net user sshd /delete - modified the last part (rid?) of the sid belonging to user/account 'sshd' in (in /etc/passwd) - rebooted Before reboot, I changed 'sshd' in an automatic service (was: manual) After the system had rebooted: - 'cygrunsrv -Q sshd' shows 'sshd' running ... - 'tail -f /var/log/sshd.log' shows 'sshd' listening ... - 'net user' shows user/account 'sshd' gone ... I can still use ssh ... (both password authentication and key authentication) Yes, if I remove user/account 'sshd' completely from /etc/passwd, only then 'sshd' won't start ... Regards, Henri = -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On 2017-05-29 21:57, Andrey Repin wrote: Greetings, Houder! - however, the userid of the grandchild of the sshd listener, is STILL cyg_server ... NOT sshd! Exactly. cyg_server is the user which does impersonation. You've been told that when you've been setting up your host. http://www.citi.umich.edu/u/provos/ssh/privsep.html https://security.stackexchange.com/questions/115896/can-someone-explain-how-sshd-does-privilege-separation https://cygwin.com/ml/cygwin/2017-05/msg00468.html 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). As far as it is documented. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
Greetings, Houder! > - however, the userid of the grandchild of the sshd listener, is STILL > cyg_server ... NOT sshd! Exactly. cyg_server is the user which does impersonation. You've been told that when you've been setting up your host. > 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). As far as it is documented. -- With best regards, Andrey Repin Monday, May 29, 2017 22:56:04 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
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: [snip] ... 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 ... Gr. Henri Hi Houder, please read the last Announcement https://sourceware.org/ml/cygwin-announce/2017-03/msg00028.html [snip] It seems you misunderstood the communication: - the possibility to NOT use "privilege separation" is deprecated - "privilege separation" will became mandatory Hi Marco, Sorry for the misunderstanding. Yes, to my knowledge, PS, privilege separation, is now mandatory (using a new mechanism under Linux [1]). [1] sandboxing? 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: https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview ... and read it MULTIPLE times! (and tried, well, about anything) However, I found a clue here: https://sourceware.org/ml/cygwin/2011-10/msg00035.html (Re: admin privileges when logging in by ssh? -- by Corinna) The thread starts here: https://cygwin.com/ml/cygwin/2011-09/msg00138.html (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 full 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. Cygwin fetches this token and uses that when switching the user context. = Oh? Ah! 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). Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
