From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16037 invoked by alias); 27 Jan 2019 17:48:37 -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 16028 invoked by uid 89); 27 Jan 2019 17:48:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=vulnerable, 20000, administration, carrier X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Jan 2019 17:48:35 +0000 Received: from [192.168.15.105] ([46.208.20.9]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LxPuE-1hGj9Z3GaQ-016wHk for ; Sun, 27 Jan 2019 18:48:31 +0100 Subject: Re: sshd permits logon using disabled user? To: cygwin@cygwin.com References: <1690850474.834980.1548391349102.ref@mail.yahoo.com> <1690850474.834980.1548391349102@mail.yahoo.com> <20190125174833.GA1710@zebra> Reply-To: cygwin@cygwin.com From: "Sam Edge (Cygwin)" Openpgp: preference=signencrypt Message-ID: Date: Sun, 27 Jan 2019 17:48:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00240.txt.bz2 On 25/01/2019 18:03, Bill Stewart wrote: > On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier > wrote: > >> There are different paths to access and to completely disable the account >> you need to close all of them. There are many reasons to disable some >> paths without disabling all paths and converting the switch that can >> disable one path to a switch that will disable all paths will break >> some setups and be less flexible. (As Stefan Baur is pointing out >> effectively.) >> >> To disable ssh logins really, instead of changing the way Cygwin works >> for everyone, you could do what UNIX/Linux admins do, something like >> moving the user .ssh folder to .ssh.disabled. > This is a very problematic view from a Windows system management perspective. > > I respectfully (and strongly) disagree, for at least the following reasons: > > * Cygwin runs on Windows, and as such should respect Windows security. > It is very unexpected, from a Windows administration perspective, to > have a disabled account and still be able to log onto it. > > * Proper system management/security mitigation is made quite complex > with this requirement. Imagine even a small Windows domain: I have to > scan 20000 machines in my domain to find out if they're running ssh, > troll through the disks to find ssh config files, find out the key > file names, rename them, etc. This is quite a bit harder to do than > just disabling accounts, which in many organizations is handled by an > automated process. > > Regards, > > Bill I totally agree that Cygwin should respect the Windows disabled & locked-out semantics and disallow any form of login where either is set. Trying to shoe-horn the disabled password but enabled pubkey function into one or the other just doesn't feel right. Setting a hugely long random password (maybe via a script that never reveals said password) is a much better solution to achieve a similar effect without breaking Windows security auditing. On the other hand, I am baffled as to why Windows itself allows a token to be created for an account that is disabled or locked out. If Cygwin can do it, other programs could too so you're still vulnerable. -- Sam Edge -- 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