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

-- 
Corinna Vinschen
Cygwin Maintainer