This is the mail archive of the
mailing list for the Cygwin project.
Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
- From: "Larry Hall (Cygwin)" <reply-to-list-only-lh at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 31 May 2017 22:27:01 -0400
- Subject: Re: openssh: privilege separation no longer supported on Cygwin? SURPRISE!
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <592E1C49.email@example.com> <firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
On 05/31/2017 05:37 AM, Houder wrote:
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
email@example.com'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
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 haven't
tested this in all environments) and one additional observation. If your
login does contain the full admin token, I could envision a benefit to
using that token when logging in, even if it seems a little counter-
intuitive (i.e. different than similar Windows usage scenarios). There
currently isn't a mechanism to elevate your privileges from the command
line using any Cygwin utility. But there is a utility to drop privileges.
It's called 'cygdrop' and it's part of the 'cygutil-extras" package. Using
this, it is possible to remove any tokens you wish to drop. So in the
scenario I postulated above, this would give you access to both possible
states but only if you start in an elevated state.
Lastly, I just want to point out that you seem to be confusing the
fact that you're telling Cygwin to use 'sshd' as the name it should assign
to a particular UID/SID mapping while there is no Windows user named 'sshd'.
Names assigned to UIDs in Cygwin do not need to match the name of the
associated SID in Windows. These concepts are completely orthogonal.
Indeed, this can be used to do very useful things, like aliasing a Windows
name containing spaces or other undesirable characters to a Cygwin user
name that doesn't have these troublesome aspects. So aliasing any SID to
a Cygwin user name/UID is a valid thing to do and should work just as well
as matching the name to the one the SID uses. I will also point out that
deleting a user in Windows does not invalidate the SID that was associated
with it. It simply makes it far less accessible. But because there could
be files on the filesystem that still reference this SID, it needs to
remain valid otherwise the filesystem would become unstable when users are
deleted. This last point isn't that significant in the scenario you've
mapped out but I mention it to hopefully help clarify the differences
between user names and SIDs in Windows.
> 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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple