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
prev parent 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).