public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Bruce Halco <bruce@halcomp.com>
To: cygwin@cygwin.com
Subject: Re: seteuid problem with sshd
Date: Thu, 14 Mar 2019 10:45:00 -0000	[thread overview]
Message-ID: <8162640b-6613-af68-af7d-4ec23009edc8@halcomp.com> (raw)
In-Reply-To: <20190314094745.GD3785@calimero.vinschen.de>



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

      reply	other threads:[~2019-03-14 10:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13 23:26 Bruce Halco
2019-03-14  0:00 ` Houder
2019-03-14  0:05 ` Andrey Repin
2019-03-14  2:20   ` Bruce Halco
2019-03-14  9:47     ` Corinna Vinschen
2019-03-14 10:45       ` Bruce Halco [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8162640b-6613-af68-af7d-4ec23009edc8@halcomp.com \
    --to=bruce@halcomp.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).