Possible Security Hole in SSHD w/ CYGWIN?

David Willis david_willis@comcast.net
Sat Feb 13 21:15:00 GMT 2016

First of all, it is one thing to ask me why I have set this up the way I did
- its another to tell me I've set it up "wrong", especially without known
the ins and outs of my domain and network.
> You still do not seem to have understood what
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
> is trying to tell you.  The windows box you log into _must_ have a
> for the user that logs into via SSH using one of the methods listed there
> order for the user credentials to become valid on the network.

So you're telling me any user that logs in using key authentication cannot
access the network as the same user (i.e. this is the intended behavior)? If
that's the case wouldn't it be better not to allow network access at ALL,
rather than allowing it as the service account that sshd is running as?

> Just why do you think that cyg_server should be a domain admin?  It only
> needs local admin membership plus some capabilities that allow it to
create a
> new user token.  Does it have those capabilities at all, i.e. what does
> editrights -lu cyg_server
> produce as output?  If it doesn't have them, then it can't actually switch
> user, password or not.

Yes it has those capabilities. I don't "think" it "needs" to be a domain
admin - yes there are other solutions such as making it a local admin
individually on each box running sshd, but currently I don't have a GPO
setup to do that, and doing it individually on each machine that runs sshd
is impractical. I am looking to implement a GPO that does just that at some
point in the near future but this is the way it is setup currently  in order
to give it local admin rights on all boxes. Like I said, I agree there are
better ways of going about this and I'm not saying the current
implementation is best practice but this is what I've got to work with

And yes I know about the other rights it needs - Act as a part of the OS,
Create a token object, Log on as a service and Replace a process-level
token. There are GPOs in place to give it those rights based on the groups
it is in.

There are also GPOs in place to prevent it from logging in interactively or
through terminal services - the ONLY logon method right it has is to logon
as a service. This is BECAUSE of the fact that it is a domain admin account,
to mitigate the access it has on the domain.

> Unless that account can authenticate fully on that box (i.e. there's a
> password), it doesn't have network access.
> This would fail if you've not set up cyg_server as a domain admin, if
> even got that far.  In fact you'd not be able to use any shares that
> authentication.

Again, so this is intended behavior when logging in with keys? And
furthermore you are saying the only reason that I have network access as the
cyg_server account is because it is a domain admin, and if it was not, there
would be no network access whatsoever?

So if I am hearing this right, anyone using SSH with key authentication
instead of password authentication, has NO network access through SSH
sessions at all? That seems unlikely, but if that's the case then so be it.

> Don't make cyg_server a domain admin, then.

Again, that is the current setup that I have to work with. And again, yes I
plan to implement a GPO to instead grant it local admin rights on each box
so that it does not need to be a domain admin to have those rights, but that
is not in place yet. Not arguing about what is best practice here, just
trying to get to the bottom of why this issue is occurring.

> I don't know how you've arrived at the setup you just described, but it's
> the one that sshd_host_config produces.  Yes, setting up an SSHD wrongly
> can open up security holes, no surprise here.

Yes you're right, it is not the one that ssh_host_config produces.
Ssh_host_config would create a SEPARATE local admin account on EVERY box its
run on. That is impractical to manage on a domain and not the setup I want.

Hopefully now you understand a little more why I've arrived at the setup I
have. I need a setup that is manageable at the domain level - I do not have
the time or resources to manage local accounts each box running sshd
individually, grant them each their own individual rights, etc. I know
cyg_server needs LOCAL admin rights - the old way of implementing this was
to use a domain account so that we don't have separate local accounts on
each box, and make it a domain admin to grant it admin rights on all servers
and workstations. I fully understand that this is not a best practice, and
like I said, there is a GPO setting that will allow local admin rights on
all boxes to a domain user w/o making them a domain admin, and this is
exactly what I plan to implement in the near future. However it is not
implemented currently, so this is the situation I am facing right now.

If you are saying without domain admin rights there would be no network
access at all granted, well, I guess that's a solution.

I prefer to keep password authentication DISABLED for security reasons
(which is highly recommended by numerous guides, including the Cygwin site
itself if I remember correctly). If however key authentication means no
access to network shares whatsoever (assuming the service account is not a
domain admin), that seems to make things difficult.

As a closing note, I've been polite here asking for help, pointing out a
possible issue. It would have been very easy to say something like "normally
no network access is allowed when logging in w/ key authentication, and
making cyg_server a domain admin is the only reason this issue is occurring,
and it is not a recommended best practice" and I would say OK thank you very
much I understand that and it makes sense. Instead of going to great lengths
to tell me how "wrong" my setup is and implying that I know nothing about
what I'm doing.

You do not understand why people have things setup the way they do and there
may be reasons behind it. So I would not be so quick to say that people have
things setup "wrong" - you could just say "if you go with that setup, this
will be an unintended side effect".

I can assure you I do understand the rights that cyg_server needs to
function, why cyg_server was made a domain admin and why I do not "go with
the default setup that ssh-host-config" provides". The one thing I did not
understand was that authenticating with a key was NOT equivalent to
authenticating with a password. I now understand that fact - I would now
suggest that in the documentation you explicitly point out that when logging
in w/ key auth, you have the rights on the network that cyg_server has. I
don't think that point is explicitly made in the documentation, and I don't
think it would be a bad idea to do so.



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

More information about the Cygwin mailing list