From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90996 invoked by alias); 14 Feb 2016 18:36:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 90983 invoked by uid 89); 14 Feb 2016 18:36:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=designs, debate, stations, installations X-HELO: mail-lf0-f51.google.com Received: from mail-lf0-f51.google.com (HELO mail-lf0-f51.google.com) (209.85.215.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 14 Feb 2016 18:36:13 +0000 Received: by mail-lf0-f51.google.com with SMTP id l143so77476524lfe.2 for ; Sun, 14 Feb 2016 10:36:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=DY0qjl5t6dul0f9cl78vLQbdasnuqkcw/gN5mnLZFcQ=; b=cBdMM0IAP5gRdP4b2IB0eSsZnM7Af5+qzmpDgOvW1BMpguXW2gjFoPvLkwKJ5Xs832 O774p6UhTe/wFtNx6axekeB8GRZefcXDlVEs6hpNquzxODJyBLXZxUv1OfyNkj65yIql H1Zsuyr7Km9062drvjOX7UKReQBNQQVv3yFSgcP0MDcGz9hupxD8DxsidDwxWgPMhyTH qrrzCyYU2xS+kxoxMBeOFnu0Zp+U1lub/3OGCkOkB7C7rRn5gRn/dBuR5gT2C1za2XJh OnjPp+M4r3VBFJ454Q1rBPz5YjFNWTzBFB2VkRmSBlJlSuL8vw+C4/uXpyfCYfjttPWz qdcg== X-Gm-Message-State: AG10YORLW96mwD+u1luLGXJArdIpuRHziT8w0hdBQdBKhE56sr0aVyx0SfCPn8gCODLANn/ws7gYDytmfVJ5hg== MIME-Version: 1.0 X-Received: by 10.25.16.214 with SMTP id 83mr5022837lfq.13.1455474969847; Sun, 14 Feb 2016 10:36:09 -0800 (PST) Received: by 10.25.86.196 with HTTP; Sun, 14 Feb 2016 10:36:09 -0800 (PST) In-Reply-To: <87a8n38t3r.fsf@Rainer.invalid> References: <019c01d163bc$fe2fc500$fa8f4f00$@comcast.net> <019e01d163c2$d678c7e0$836a57a0$@comcast.net> <023901d165e4$925507d0$b6ff1770$@comcast.net> <87d1s1c8ld.fsf@Rainer.invalid> <87a8n38t3r.fsf@Rainer.invalid> Date: Sun, 14 Feb 2016 18:36:00 -0000 Message-ID: Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? From: Erik Soderquist To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00215.txt.bz2 On Sun, Feb 14, 2016 at 5:49 AM, Achim Gratz wrote: > Erik Soderquist writes: >> I would suspect Domain Admin for the Cyg_server account is a >> requirement of David's environment, which neither of us know anything >> about at present. I know I've had to do things that were not "best >> practice" due to corporate policy on more occasions than I care to >> count. > > If that's the case, then security of the sshd is the least of your > worries and I wouldn't install sshd at all. Again, not always optional if you are not the one dictating corporate polic= y. >> Actually the Cygwin doc does include instructions for accessing >> network shares when using ssh public key authentication. > > =E2=80=A6which boil down to the password being stored (obscured) on the m= achine > running sshd in order for sshd to obtain the necessary authentication > via password-based login. Very true, but depending on the site configuration, there is at least arguably more security in the password being stored on the machine rather than passed across the network for the initial sshd connection. This is very open to debate, but that debate isn't the topic of this thread. The point of this reference was that yes, there are designs included to give network access to a user logged in via ssh using public key authentication. >> Once again, assumptions. While I can't explicitly vouch for David's >> environment, as I do not have access to check, I can vouch for mine, >> and mine was configured using sshd_host_config, with the only changes >> after sshd_host_config being regarding TCP and X tunneling. > > I have to again make an assumption, namely that if cyg_server is a local > account you've checked the C$ share of the same server that sshd is > running on. That's bad enough, shouldn't happen and needs fixing, but > at least you wouldn't be able to access any network shares from other > servers that weren't otherwise accessible for everybody. Valid assumption this time, yes I accessed c$ on the local host, though in my past experience, I would expect it to work on remote hosts as well in this scenario if the local and remote cyg_server account use the same password. For scripted installations across many hosts, I would expect them to have the same password. I can set this up to test and confirm it, but that will take a bit of time. Most of my stations are *nix already. I think the key point is that if no network password is stored using the "passwd -R" option, then there should be absolutely no network access at all in the current code/design, not a fall through to the cyg_server account's network access, regardless of how much or little network access that account has. -- Erik. -- 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