X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; q=dns; s=default; b=YuG2y
	PND+OaMB5jS2Gb1FhjA8GIt/qcgJtbUSyJCVQc+5xqBjDI/z6cia1UnyAJrdN7BT
	UmRXnhVurKidcUYafM/hEuBlOkKPU2KIHjDavGF+ELI5SIAGole2i2d+8WmpuGzj
	BnGTmpAvEZtfBOPxCTrpcazfKKP2Ie0e3b/HAc=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; s=default; bh=m3sPsMCT95H
	fYMRD3XDdizeUwX4=; b=SbjAP77o+y89kghQCCY7XoGes8AFoRaX4s4weSExPeY
	cqgRvNtqzVGKOD/gKhciuMmi6NJA7KBk9Xv4vrO6fzo/gbb/Qyhy4r5MMpzcD+Ow
	DiEKCyJ27kaOgocWd51CGnOJ+OSWIuksVz4dTxCYAKuxHZndEup9KQjwmaU0CgUs
	=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=insisting, UD:technet.microsoft.com, technetmicrosoftcom, sk:technet
X-HELO:	mail-in-10.arcor-online.net
X-DKIM:	Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 3q350H6sVRz31hF
From:	Achim Gratz <Stromeko AT nexgo DOT de>
To:	cygwin AT cygwin DOT com
Subject:	Re: Possible Security Hole in SSHD w/ CYGWIN?
References:	<019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <CANnLRdhVrFcveO_jKb3_x=44WMJNO33DPnsJZ12Wus3U7Wo_fQ AT mail DOT gmail DOT com> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> <87d1s1c8ld DOT fsf AT Rainer DOT invalid> <024901d166a3$a6930390$f3b90ab0$@comcast.net>
Date:	Sun, 14 Feb 2016 11:48:59 +0100
In-Reply-To:	<024901d166a3$a6930390$f3b90ab0$@comcast.net> (David Willis's message of "Sat, 13 Feb 2016 13:15:22 -0800")
Message-ID:	<87bn7j8t44.fsf@Rainer.invalid>
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux)
MIME-Version:	1.0

David Willis writes:
> 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?

You don't have access to anything beyond the machine you've logged into
associated with that user account until you create a new logon session
for that account on that machine and you need to have the password for
this token to be created.  The same thing happens if you leave a remote
desktop session lingering for a day or so, you will then have to give
your password anew since those tokens or rather the Kerberos tickets
based on them will expire.  If you don't do that, you are still logged
into the machine in question and can do pretty much anything there as
you are used to, but you are no longer authenticated for network access.

> 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?

You could access whatever anybody could access who is authenticated
locally or a machine that has joined the domain; that shouldn't be much.
But anything requiring more specific access rights associated with your
user account would be denied because you're not fully authenticated.

> 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.

Either that (assuming that you can't use a share that everyone has
access to, which is unlikely) or you'd use the "passwd -R" dance, which
is iffy in it's own right and certainly not something that you should
roll out to just about any machine.  Plus all the users have to remember
that each time they're changing their passwords they also need to do the
"passwd -R" again on each machine they ssh into lest they lock
themselves out pretty quickly.

Another option is to use password authentication on the first login to
each server, then start another sshd as that user from the session just
established and then use that secondary sshd with public key login.  The
secondary sshd would probably have to be restarted after a certain time
when the Kerberos tickets expire.

> 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.

What you want to do can (and should) be done without giving cyg_server
domain admin rights.  It needs to be restricted as much as possible,
given that it already has some very powerful capabilities.  You haven't
described the rest of the setup process for sshd on each box, so I won't
comment on the practicality of using local accounts anyway.  I am quite
happy with using a local account since it allows me to give each
cyg_server a completely random password that works on just that machine
and nowhere else and doesn't need to be recorded anywhere after the
services have been installed.

> 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".

However stingy you felt my remark about your application of the domain
admin right was, I keep insisting that you shouldn't use it in that way,
even if it seems to do what you want.  It also does lots of things you
absolutely don't want.  In fact, there should be no permanently active
accounts with domain admin rights anywhere on your network if you care
about security.

https://technet.microsoft.com/en-us/library/dn487454.aspx
https://www.beyondtrust.com/blog/best-practices-for-managing-domain-admin-accounts/

> The one thing I did not
> understand was that authenticating with a key was NOT equivalent to
> authenticating with a password.

That's the whole point of

https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

although it may seem somewhat long-winded.  If you think that the
documentation can be improved, I'm sure Corinna doesn't mind getting a
patch.

> 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.

That may actually be an unintended consequence of how Windows deals with
the Kerberos tickets that govern network access and should be considered
a bug.  I'm not sure if or how that can be avoided, but it would be nice
if sshd did not present those tickets at all.  But there wouldn't have
been a valid ticket to present if you hadn't made cyg_server a domain
admin.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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

- Raw text -