Bill, On Jan 25 11:03, Bill Stewart wrote: > On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier > <carr...@berkeley.edu> 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.
Can you please test again with the latest snapshot from https://cygwin.com/snapshots/? The new S4U authentication method used in this snapshot automatically applies the Windows account rules so in my testing the patch I applied originally is not required anymore. Consequentially I disabled it to rely fully on the Windows function's behaviour. Can you test this, too, please, just to be sure? Thanks, Coinna -- Corinna Vinschen Cygwin Maintainer
signature.asc
Description: PGP signature
