From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18766 invoked by alias); 14 Mar 2019 10:45:39 -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 18641 invoked by uid 89); 14 Mar 2019 10:45:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=practices, password, risk, HContent-Transfer-Encoding:8bit X-HELO: mout.perfora.net Received: from mout.perfora.net (HELO mout.perfora.net) (74.208.4.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Mar 2019 10:45:37 +0000 Received: from [192.168.0.2] ([24.209.49.167]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MWAcp-1hXHew1RGr-00XKLZ for ; Thu, 14 Mar 2019 11:45:35 +0100 Subject: Re: seteuid problem with sshd To: cygwin@cygwin.com References: <68371e6b-aee9-4e70-d079-098160f7bf61@halcomp.com> <1231848485.20190314025011@yandex.ru> <032d1268-15e7-f10d-bdd7-45effb6b6a2b@halcomp.com> <20190314094745.GD3785@calimero.vinschen.de> From: Bruce Halco Message-ID: <8162640b-6613-af68-af7d-4ec23009edc8@halcomp.com> Date: Thu, 14 Mar 2019 10:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190314094745.GD3785@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-03/txt/msg00364.txt.bz2 On 3/14/19 5:47 AM, Corinna Vinschen wrote: > On Mar 13 22:20, Bruce Halco wrote: >> I had found nothing referencing "No such file or directory", which sounds >> rather different from a permissions problem. >> >> Running sshd under the Local System account made no difference. >> >> passwd -R was no help. >> >> What I did discover was that cygwin/sshd apparently now requires the Windows >> account to be Enabled.  That was not the case previously. >> >> The target systems in my application are in restaurant offices, and only use >> a single Windows login. >> >> As the people who use ssh do not need local Windows accounts, I've always >> used the practice of Disabling those user accounts in Windows. The >> credentials were available to ssh, without the security issues of all those >> extra active accounts. >> >> Unless someone can suggest an alternative, I'll have to leave all those >> accounts Enabled. I can put some long, nasty passwords on them to keep the >> risk acceptable. > I'm sorry to say that, but there is no alternative. This has been > discussed at great length on thlis mailing list, starting at > > https://cygwin.com/ml/cygwin/2019-01/msg00197.html > > For starters, I added a special check to disable logging in with a > disabled account. However, the S4U logon method used by Cygwin now in > place of the old "Create user token from scratch" method(*) even checks > that automatically and does not allow disabled accounts to logon. > > Same goes for the `passwd -R' method as well as for normal password logon > since they have been introduced, btw, given they use the same underlying > WIndows function which actively checks for disabled accounts. > > Last but not least, the fact that some logon methods allowed disabled > accounts to logon and some didn't wasn't really a good idea to begin > with. > > > Corinna > > (*) https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1 > Thank you for the information. I will adjust my practices to the new situation. Bruce -- 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