This is the mail archive of the
mailing list for the Cygwin project.
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
On Tue, 30 May 2017 21:28:41, "Larry Hall (Cygwin)" wrote:
> 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.
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 xxxx in the sid)
However, just now I modified it as follows:
(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 ...
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  (in stead it belongs to user cyg_server).
 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.
>From an UNelevated shell:
64-@@ ssh -p <SOME-PORT> -l Henri 192.168.178.15
Enter passphrase for key '/home/Henri/.ssh/<SOME-KEY>': # Henri is privileged
Last login: Wed May 31 10:30:52 2017 from 192.168.178.15
TADA !!!!! <==== contents of /etc/motd
64-@@# exit <==== full-blown elevated shell! (try whoami /all)
Connection to 192.168.178.15 closed.
64-@@ ssh -p <SOME-PORT> -l jvdwater 192.168.178.15
firstname.lastname@example.org's password: # jvdwater is UNprivileged
Last login: Wed May 31 10:29:27 2017 from 192.168.178.15
64-@@ exit <==== ordinary UNelevated shell
Connection to 192.168.178.15 closed.
64-@@# tail -f /var/log/sshd.log
Server listening on 0.0.0.0 port <SOME-PORT>.
Accepted publickey for Henri from 192.168.178.15 port 49186 ssh2: <SOME-KEY>
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple