Re: sshd permits logon using disabled user?

Re: sshd permits logon using disabled user?

[matthew patton via cygwin]

 > I think refusing an account manually and deliberately disabled by an
 > admin makes lots of sense.

Why is this even a discussion? You *ALWAYS* refuse a login to an account that is disabled, locked out, or has an expired password or failed any of the other criteria that might be in effect (day/time restrictions, source IP restrictions, etc.)

Is someone suggesting that the Windows authentication API is actually returning a success code despite any of these conditions?

Furthermore you also *NEVER* hint to the user why the login was denied. It's rule #1 of security engineering.
Denied is denied. Explanations or hints are verboten.

--
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

Re: sshd permits logon using disabled user?

[Stefan Baur]

Am 25.01.19 um 05:42 schrieb matthew patton via cygwin:
> Why is this even a discussion? You *ALWAYS* refuse a login to an account that is disabled, locked out, or has an expired password or failed any of the other criteria that might be in effect (day/time restrictions, source IP restrictions, etc.)

Not on Linux (and possibly other Unices).  There, it's perfectly valid
to disable an account's password login (both locally and remote), but to
at the same time allow ssh key file based logins for the same account.

Since cygwin aims to be Linux-/POSIX-compatible to a certain degree, it
is indeed worthy of discussion - even if the final decision might be to
just block logins completely, even with an ssh key pair.

Before Corinna pushed her fix, it was possible to log in via SSH key,
even when the account was locked out/disabled.  Someone might have been
using that "feature" on cygwin, knowing it from Linux, where it is
indeed a feature/design choice.

If this fix hits stable, the same people might be wondering why their
ssh logins fail all of a sudden.

This could be a scenario for scripted uploads via rsync/scp/sftp, for
example, where people are using ssh keys locked down to certain
commands.  You just don't want that user account to be able to log in
with only a password, ever - because the only reason that would happen
would be an account compromise.  And because of that, having a "there is
no valid password for this account, you can try as hard as you like"
setting makes more sense than just setting a long and complex password
that hopefully no one ever guesses/bruteforces/sidechannel-hacks/...

Kind Regards,
Stefan Baur


-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

--
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

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Fri, Jan 25, 2019 at 3:36 AM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:

> Not on Linux (and possibly other Unices).  There, it's perfectly valid
> to disable an account's password login (both locally and remote), but to
> at the same time allow ssh key file based logins for the same account.

But disabling _password login_ is an entirely separate issue from
disabling _the account itself_.

Before the fix, it was possible to log on to sshd using a disabled (or
locked) account.

There should be _no_ scenario where it is possible to log on using a
disabled/locked account.

(To state the obvious: That's the whole point of having
disabled/locked out flags - so the account cannot be used to log on.)

Regards,

Bill

--
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

Re: sshd permits logon using disabled user?

[Stephen Paul Carrier]

On Fri, Jan 25, 2019 at 08:34:09AM -0700, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 3:36 AM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
> 
> > Not on Linux (and possibly other Unices).  There, it's perfectly valid
> > to disable an account's password login (both locally and remote), but to
> > at the same time allow ssh key file based logins for the same account.
> 
> But disabling _password login_ is an entirely separate issue from
> disabling _the account itself_.
> 
> Before the fix, it was possible to log on to sshd using a disabled (or
> locked) account.
> 
> There should be _no_ scenario where it is possible to log on using a
> disabled/locked account.

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.

Stephen Carrier
Systems Administrator 
BEAR (Berkeley Evaluation & Assessment Research) Center
Graduate School of Education
University of California, Berkeley
http://BEARcenter.Berkeley.EDU/
carrier@Berkeley.EDU

--
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

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
<carrier@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.

Regards,

Bill

--
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

Re: sshd permits logon using disabled user?

[Sam Edge (Cygwin)]

On 25/01/2019 18:03, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
> <carrier@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.
>
> Regards,
>
> Bill


I totally agree that Cygwin should respect the Windows disabled &
locked-out semantics and disallow any form of login where either is set.
Trying to shoe-horn the disabled password but enabled pubkey function
into one or the other just doesn't feel right. Setting a hugely long
random password (maybe via a script that never reveals said password) is
a much better solution to achieve a similar effect without breaking
Windows security auditing.

On the other hand, I am baffled as to why Windows itself allows a token
to be created for an account that is disabled or locked out. If Cygwin
can do it, other programs could too so you're still vulnerable.

-- 
Sam Edge


--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3594 bytes --]

On Jan 27 17:49, Sam Edge (Cygwin) wrote:
> On 25/01/2019 18:03, Bill Stewart wrote:
> > On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
> > <carrier@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.
> >
> > Regards,
> >
> > Bill
> 
> 
> I totally agree that Cygwin should respect the Windows disabled &
> locked-out semantics and disallow any form of login where either is set.
> Trying to shoe-horn the disabled password but enabled pubkey function
> into one or the other just doesn't feel right. Setting a hugely long
> random password (maybe via a script that never reveals said password) is
> a much better solution to achieve a similar effect without breaking
> Windows security auditing.
> 
> On the other hand, I am baffled as to why Windows itself allows a token
> to be created for an account that is disabled or locked out. If Cygwin
> can do it, other programs could too so you're still vulnerable.

No, Windows doesn't allow that unless the process has very specific
privileges.  But keep in mind that a token is required to do stuff on
behalf of a user.  So even if the user is disabled from interactive
logon, a service process might have a valid reason to create a token
for that user to perform a non-interactive purpose.

In terms of these special privileges, right now we require these
privileges for an account which switches the user (e.g., via sshd
installed as a service), as outlined in
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1

However, this should change with the upcoming 3.0 release of Cygwin
which replaces the "create token" method with another method called
"S4U".  This method creates perfectly valid tokens with only documented
functions without requiring any super-special permissions.

I'm pretty excited about this change because it drops the requirement
to create a special CYgwin service account.  sshd and other services
can finally run under the normal LocalSystem account again.

This patch is available in the most recent developer snapshot from
https://cygwin.com/snapshots/ btw.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Sam Edge]

On 27/01/2019 22:10, Corinna Vinschen wrote:
> On Jan 27 17:49, Sam Edge (Cygwin) wrote:
>> On 25/01/2019 18:03, Bill Stewart wrote:
>>> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
>>> <carrier@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.
>>>
>>> Regards,
>>>
>>> Bill
>>
>> I totally agree that Cygwin should respect the Windows disabled &
>> locked-out semantics and disallow any form of login where either is set.
>> Trying to shoe-horn the disabled password but enabled pubkey function
>> into one or the other just doesn't feel right. Setting a hugely long
>> random password (maybe via a script that never reveals said password) is
>> a much better solution to achieve a similar effect without breaking
>> Windows security auditing.
>>
>> On the other hand, I am baffled as to why Windows itself allows a token
>> to be created for an account that is disabled or locked out. If Cygwin
>> can do it, other programs could too so you're still vulnerable.
> No, Windows doesn't allow that unless the process has very specific
> privileges.  But keep in mind that a token is required to do stuff on
> behalf of a user.  So even if the user is disabled from interactive
> logon, a service process might have a valid reason to create a token
> for that user to perform a non-interactive purpose.
>
> In terms of these special privileges, right now we require these
> privileges for an account which switches the user (e.g., via sshd
> installed as a service), as outlined in
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
>
> However, this should change with the upcoming 3.0 release of Cygwin
> which replaces the "create token" method with another method called
> "S4U".  This method creates perfectly valid tokens with only documented
> functions without requiring any super-special permissions.
>
> I'm pretty excited about this change because it drops the requirement
> to create a special CYgwin service account.  sshd and other services
> can finally run under the normal LocalSystem account again.
>
> This patch is available in the most recent developer snapshot from
> https://cygwin.com/snapshots/ btw.
>
>
> Corinna
>
Hi Corinna. Thanks for the explanation. And the heads-up on the change.
Having a rummage through docs out of curiosity. (Tangential to my day job.)

I think I grok Win32 and Linux FS ACLs but my expertise on OS process
security models peaked somewhere around System V. :-S

Anyway, the fact that activity can still occur in the name of
disabled/locked-out accounts is, perhaps, something that people in
Bill's position should consider, given his concerns. But that's rather OT.

As ever, kudos to yourself and the rest of the contributors to Cygwin.
Still my go-to tool wherever I land.




--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

Bill,

On Jan 25 11:03, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
> <carrier@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:

> 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?

Thank you Corinna; I will test.

Will the S4U authentication work on standalone (non domain-joined)
machines also?

Bill

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Jan 28 08:02, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> 
> > 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?
> 
> Thank you Corinna; I will test.
> 
> Will the S4U authentication work on standalone (non domain-joined)
> machines also?

It uses MsV1_0 S4U on standalone workstations, Kerberos S4U on domain
meber machines with fallback to MsV1_0 under some circumstances.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Mon, Jan 28, 2019 at 9:52 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
>
> On Jan 28 08:02, Bill Stewart wrote:
> > On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
> > <corinna-cygwin@cygwin.com> wrote:
> >
> > > 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?
> >
> > Thank you Corinna; I will test.
> >
> > Will the S4U authentication work on standalone (non domain-joined)
> > machines also?
>
> It uses MsV1_0 S4U on standalone workstations, Kerberos S4U on domain
> meber machines with fallback to MsV1_0 under some circumstances.

Hi Corinna,

This is great that the service can run using the SYSTEM account! It
greatly simplifies management.

I tested and it worked as expected.

Thank you!

Bill

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1.1: Type: text/plain, Size: 1727 bytes --]

On Jan 28 10:18, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 9:52 AM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> >
> > On Jan 28 08:02, Bill Stewart wrote:
> > > On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
> > > <corinna-cygwin@cygwin.com> wrote:
> > >
> > > > 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?
> > >
> > > Thank you Corinna; I will test.
> > >
> > > Will the S4U authentication work on standalone (non domain-joined)
> > > machines also?
> >
> > It uses MsV1_0 S4U on standalone workstations, Kerberos S4U on domain
> > meber machines with fallback to MsV1_0 under some circumstances.
> 
> Hi Corinna,
> 
> This is great that the service can run using the SYSTEM account! It
> greatly simplifies management.

Along these lines I have an OpenSSH patch in the loop which reverts
the ssh-host-config script back to using the SYSTEM user, just as
in the olden Windows XP days.  I'll send it upstream as soon as
Cygwin 3.0 is officially released.  I attached the resulting
ssh-host-config script to this mail, if you or anybody else want
to test it.

> I tested and it worked as expected.
> 
> Thank you!

Super, thank you!  I guess I will role out a Cygwin test release in the
next couple of days.


Stay tuned,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #1.2: ssh-host-config --]
[-- Type: text/plain, Size: 23382 bytes --]

#!/bin/bash
#
# ssh-host-config, Copyright 2000-2014 Red Hat Inc.
#
# This file is part of the Cygwin port of OpenSSH.
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS  
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF               
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.   
# IN NO EVENT SHALL THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,   
# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR    
# OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR    
# THE USE OR OTHER DEALINGS IN THE SOFTWARE.                               

# ======================================================================
# Initialization
# ======================================================================

CSIH_SCRIPT=/usr/share/csih/cygwin-service-installation-helper.sh

# List of apps used.  This is checkad for existence in csih_sanity_check
# Don't use *any* transient commands before sourcing the csih helper script,
# otherwise the sanity checks are short-circuited.
declare -a csih_required_commands=(
  /usr/bin/basename coreutils
  /usr/bin/cat coreutils
  /usr/bin/chmod coreutils
  /usr/bin/dirname coreutils
  /usr/bin/id coreutils
  /usr/bin/mv coreutils
  /usr/bin/rm coreutils
  /usr/bin/cygpath cygwin
  /usr/bin/mkpasswd cygwin
  /usr/bin/mount cygwin
  /usr/bin/ps cygwin
  /usr/bin/umount cygwin
  /usr/bin/cmp diffutils
  /usr/bin/grep grep
  /usr/bin/awk gawk
  /usr/bin/ssh-keygen openssh
  /usr/sbin/sshd openssh
  /usr/bin/sed sed
)
csih_sanity_check_server=yes
source ${CSIH_SCRIPT}

PROGNAME=$(/usr/bin/basename $0)
_tdir=$(/usr/bin/dirname $0)
PROGDIR=$(cd $_tdir && pwd)

# Subdirectory where the new package is being installed
PREFIX=/usr

# Directory where the config files are stored
SYSCONFDIR=/etc
LOCALSTATEDIR=/var

sshd_config_configured=no
port_number=22
service_name=cygsshd
strictmodes=yes
cygwin_value=""
user_account=
password_value=
opt_force=no

# ======================================================================
# Routine: update_services_file
# ======================================================================
update_services_file() {
  local _my_etcdir="/ssh-host-config.$$"
  local _win_etcdir
  local _services
  local _spaces
  local _serv_tmp
  local _wservices
  local ret=0

  _win_etcdir="${SYSTEMROOT}\\system32\\drivers\\etc"
  _services="${_my_etcdir}/services"
  _spaces="                           #"
  _serv_tmp="${_my_etcdir}/srv.out.$$"

  /usr/bin/mount -o text,posix=0,noacl -f "${_win_etcdir}" "${_my_etcdir}"

  # Depends on the above mount
  _wservices=`cygpath -w "${_services}"`

  # Add ssh 22/tcp  and ssh 22/udp to services
  if [ `/usr/bin/grep -q 'ssh[[:space:]][[:space:]]*22' "${_services}"; echo $?` -ne 0 ]
  then
    if /usr/bin/awk '{ if ( $2 ~ /^23\/tcp/ ) print "ssh                22/tcp'"${_spaces}"'SSH Remote Login Protocol\nssh                22/udp'"${_spaces}"'SSH Remote Login Protocol"; print $0; }' < "${_services}" > "${_serv_tmp}"
    then
      if /usr/bin/mv "${_serv_tmp}" "${_services}"
      then
	csih_inform "Added ssh to ${_wservices}"
      else
	csih_warning "Adding ssh to ${_wservices} failed!"
	let ++ret
      fi
      /usr/bin/rm -f "${_serv_tmp}"
    else
      csih_warning "Adding ssh to ${_wservices} failed!"
      let ++ret
    fi
  fi
  /usr/bin/umount "${_my_etcdir}"
  return $ret
} # --- End of update_services_file --- #

# ======================================================================
# Routine: sshd_strictmodes
#  MODIFIES: strictmodes
# ======================================================================
sshd_strictmodes() {
  if [ "${sshd_config_configured}" != "yes" ]
  then
    echo
    csih_inform "StrictModes is set to 'yes' by default."
    csih_inform "This is the recommended setting, but it requires that the POSIX"
    csih_inform "permissions of the user's home directory, the user's .ssh"
    csih_inform "directory, and the user's ssh key files are tight so that"
    csih_inform "only the user has write permissions."
    csih_inform "On the other hand, StrictModes don't work well with default"
    csih_inform "Windows permissions of a home directory mounted with the"
    csih_inform "'noacl' option, and they don't work at all if the home"
    csih_inform "directory is on a FAT or FAT32 partition."
    if ! csih_request "Should StrictModes be used?"
    then
      strictmodes=no
    fi
  fi
  return 0
}

# ======================================================================
# Routine: sshd_privsep
# Try to create ssshd user account
# ======================================================================
sshd_privsep() {
  local ret=0

  if [ "${sshd_config_configured}" != "yes" ]
  then
    if ! csih_create_unprivileged_user sshd
    then
      csih_error_recoverable "Could not create user 'sshd'!"
      csih_error_recoverable "You will not be able to run an sshd service"
      csih_error_recoverable "under a privileged account successfully."
      csih_error_recoverable "Make sure to create a non-privileged user 'sshd'"
      csih_error_recoverable "manually before trying to run the service!"
      let ++ret
    fi
  fi
  return $ret
} # --- End of sshd_privsep --- #

# ======================================================================
# Routine: sshd_config_tweak
# ======================================================================
sshd_config_tweak() {
  local ret=0

  # Modify sshd_config
  csih_inform "Updating ${SYSCONFDIR}/sshd_config file"
  if [ "${port_number}" -ne 22 ]
  then
    /usr/bin/sed -i -e "s/^#\?[[:space:]]*Port[[:space:]].*/Port ${port_number}/" \
      ${SYSCONFDIR}/sshd_config
    if [ $? -ne 0 ]
    then
      csih_warning "Setting listening port to ${port_number} failed!"
      csih_warning "Check your ${SYSCONFDIR}/sshd_config file!"
      let ++ret
    fi
  fi
  if [ "${strictmodes}" = "no" ]
  then
    /usr/bin/sed -i -e "s/^#\?[[:space:]]*StrictModes[[:space:]].*/StrictModes no/" \
      ${SYSCONFDIR}/sshd_config
    if [ $? -ne 0 ]
    then
      csih_warning "Setting StrictModes to 'no' failed!"
      csih_warning "Check your ${SYSCONFDIR}/sshd_config file!"
      let ++ret
    fi
  fi
  return $ret
} # --- End of sshd_config_tweak --- #

# ======================================================================
# Routine: update_inetd_conf
# ======================================================================
update_inetd_conf() {
  local _inetcnf="${SYSCONFDIR}/inetd.conf"
  local _inetcnf_tmp="${SYSCONFDIR}/inetd.conf.$$"
  local _inetcnf_dir="${SYSCONFDIR}/inetd.d"
  local _sshd_inetd_conf="${_inetcnf_dir}/sshd-inetd"
  local _sshd_inetd_conf_tmp="${_inetcnf_dir}/sshd-inetd.$$"
  local _with_comment=1
  local ret=0

  if [ -d "${_inetcnf_dir}" ]
  then
    # we have inetutils-1.5 inetd.d support
    if [ -f "${_inetcnf}" ]
    then
      /usr/bin/grep -q '^[[:space:]]*ssh' "${_inetcnf}" && _with_comment=0

      # check for sshd OR ssh in top-level inetd.conf file, and remove
      # will be replaced by a file in inetd.d/
      if [ $(/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?) -eq 0 ]
      then
	/usr/bin/grep -v '^[# \t]*ssh' "${_inetcnf}" >> "${_inetcnf_tmp}"
	if [ -f "${_inetcnf_tmp}" ]
	then
	  if /usr/bin/mv "${_inetcnf_tmp}" "${_inetcnf}"
	  then
  	    csih_inform "Removed ssh[d] from ${_inetcnf}"
	  else
  	    csih_warning "Removing ssh[d] from ${_inetcnf} failed!"
	    let ++ret
	  fi
	  /usr/bin/rm -f "${_inetcnf_tmp}"
	else
	  csih_warning "Removing ssh[d] from ${_inetcnf} failed!"
	  let ++ret
	fi
      fi
    fi

    csih_install_config "${_sshd_inetd_conf}"   "${SYSCONFDIR}/defaults"
    if /usr/bin/cmp "${SYSCONFDIR}/defaults${_sshd_inetd_conf}" "${_sshd_inetd_conf}" >/dev/null 2>&1
    then
      if [ "${_with_comment}" -eq 0 ]
      then
	/usr/bin/sed -e 's/@COMMENT@[[:space:]]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}"
      else
	/usr/bin/sed -e 's/@COMMENT@[[:space:]]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}"
      fi
      if /usr/bin/mv "${_sshd_inetd_conf_tmp}" "${_sshd_inetd_conf}"
      then
	csih_inform "Updated ${_sshd_inetd_conf}"
      else
	csih_warning "Updating ${_sshd_inetd_conf} failed!"
	let ++ret
      fi
    fi

  elif [ -f "${_inetcnf}" ]
  then
    /usr/bin/grep -q '^[[:space:]]*sshd' "${_inetcnf}" && _with_comment=0

    # check for sshd in top-level inetd.conf file, and remove
    # will be replaced by a file in inetd.d/
    if [ `/usr/bin/grep -q '^#\?[[:space:]]*sshd' "${_inetcnf}"; echo $?` -eq 0 ]
    then
      /usr/bin/grep -v '^#\?[[:space:]]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}"
      if [ -f "${_inetcnf_tmp}" ]
      then
	if /usr/bin/mv "${_inetcnf_tmp}" "${_inetcnf}"
	then
	    csih_inform "Removed sshd from ${_inetcnf}"
	else
	    csih_warning "Removing sshd from ${_inetcnf} failed!"
	    let ++ret
	fi
	/usr/bin/rm -f "${_inetcnf_tmp}"
      else
	csih_warning "Removing sshd from ${_inetcnf} failed!"
	let ++ret
      fi
    fi

    # Add ssh line to inetd.conf
    if [ `/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -ne 0 ]
    then
      if [ "${_with_comment}" -eq 0 ]
      then
	echo 'ssh  stream  tcp     nowait  root    /usr/sbin/sshd sshd -i' >> "${_inetcnf}"
      else
	echo '# ssh  stream  tcp     nowait  root    /usr/sbin/sshd sshd -i' >> "${_inetcnf}"
      fi
      if [ $? -eq 0 ]
      then
	csih_inform "Added ssh to ${_inetcnf}"
      else
	csih_warning "Adding ssh to ${_inetcnf} failed!"
	let ++ret
      fi
    fi
  fi
  return $ret
} # --- End of update_inetd_conf --- #

# ======================================================================
# Routine: check_service_files_ownership
#   Checks that the files in /etc and /var belong to the right owner
# ======================================================================
check_service_files_ownership() {
  local run_service_as=$1
  local ret=0

  if [ -z "${run_service_as}" ]
  then
    accnt_name=$(/usr/bin/cygrunsrv -VQ "${service_name}" |
    		 /usr/bin/sed -ne 's/^Account *: *//gp')
    if [ "${accnt_name}" = "LocalSystem" ]
    then
      # Convert "LocalSystem" to "SYSTEM" as is the correct account name
      run_service_as="SYSTEM"
    else
      dom="${accnt_name%%\\*}"
      accnt_name="${accnt_name#*\\}"
      if [ "${dom}" = '.' ]
      then
	# Check local account
	run_service_as=$(/usr/bin/mkpasswd -l -u "${accnt_name}" |
			 /usr/bin/awk -F: '{print $1;}')
      else
      	# Check domain
	run_service_as=$(/usr/bin/mkpasswd -d "${dom}" -u "${accnt_name}" |
			 /usr/bin/awk -F: '{print $1;}')
      fi
    fi
    if [ -z "${run_service_as}" ]
    then
      csih_warning "Couldn't determine name of user running ${service_name} service from account database!"
      csih_warning "As a result, this script cannot make sure that the files used"
      csih_warning "by the ${service_name} service belong to the user running the service."
      return 1
    fi
  fi
  for i in "${SYSCONFDIR}"/ssh_config "${SYSCONFDIR}"/sshd_config "${SYSCONFDIR}"/ssh_host_*key "${SYSCONFDIR}"/ssh_host_*key.pub
  do
    if [ -f "$i" ]
    then
      if ! chown "${run_service_as}".544 "$i" >/dev/null 2>&1
      then
	csih_warning "Couldn't change owner of $i!"
	let ++ret
      fi
    fi
  done
  if ! chown "${run_service_as}".544 ${LOCALSTATEDIR}/empty >/dev/null 2>&1
  then
    csih_warning "Couldn't change owner of ${LOCALSTATEDIR}/empty!"
    let ++ret
  fi
  if ! chown "${run_service_as}".544 ${LOCALSTATEDIR}/log/lastlog >/dev/null 2>&1
  then
    csih_warning "Couldn't change owner of ${LOCALSTATEDIR}/log/lastlog!"
    let ++ret
  fi
  if [ -f ${LOCALSTATEDIR}/log/sshd.log ]
  then
    if ! chown "${run_service_as}".544 ${LOCALSTATEDIR}/log/sshd.log >/dev/null 2>&1
    then
      csih_warning "Couldn't change owner of ${LOCALSTATEDIR}/log/sshd.log!"
      let ++ret
    fi
  fi
  if [ $ret -ne 0 ]
  then
    csih_warning "Couldn't change owner of important files to ${run_service_as}!"
    csih_warning "This may cause the ${service_name} service to fail!  Please make sure that"
    csih_warning "you have sufficient permissions to change the ownership of files"
    csih_warning "and try to run the ssh-host-config script again."
  fi
  return $ret
} # --- End of check_service_files_ownership --- #

# ======================================================================
# Routine: install_service
#   Install sshd as a service
# ======================================================================
install_service() {
  local run_service_as
  local password
  local ret=0

  echo
  if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1
  then
    csih_inform "Sshd service is already installed."
    check_service_files_ownership "" || let ret+=$?
  else
    echo -e "${_csih_QUERY_STR} Do you want to install sshd as a service?"
    if csih_request "(Say \"no\" if it is already installed as a service)"
    then
      csih_get_cygenv "${cygwin_value}"

      if ( [ "$csih_FORCE_PRIVILEGED_USER" = "yes" ] )
      then
	[ "${opt_force}" = "yes" ] && opt_f=-f
	[ -n "${user_account}" ] && opt_u="-u ""${user_account}"""
	csih_select_privileged_username ${opt_f} ${opt_u} sshd

	if ! csih_create_privileged_user "${password_value}"
	then
	  csih_error_recoverable "There was a serious problem creating a privileged user."
	  csih_request "Do you want to proceed anyway?" || exit 1
	  let ++ret
	fi
	# Never returns empty if NT or above
	run_service_as=$(csih_service_should_run_as)
      else
	run_service_as="SYSTEM"
      fi

      if [ "${run_service_as}" = "${csih_PRIVILEGED_USERNAME}" ]
      then
	password="${csih_PRIVILEGED_PASSWORD}"
	if [ -z "${password}" ]
	then
	  csih_get_value "Please enter the password for user '${run_service_as}':" "-s"
	  password="${csih_value}"
	fi
      fi

      # At this point, we either have $run_service_as = "system" and
      # $password is empty, or $run_service_as is some privileged user and
      # (hopefully) $password contains the correct password.  So, from here
      # out, we use '-z "${password}"' to discriminate the two cases.

      csih_check_user "${run_service_as}"

      if [ -n "${csih_cygenv}" ]
      then
	cygwin_env=( -e "CYGWIN=${csih_cygenv}" )
      fi
      if [ -z "${password}" ]
      then
	if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \
			      -a "-D" -y tcpip "${cygwin_env[@]}"
	then
	  echo
	  csih_inform "The sshd service has been installed under the LocalSystem"
	  csih_inform "account (also known as SYSTEM). To start the service now, call"
	  csih_inform "\`net start ${service_name}' or \`cygrunsrv -S ${service_name}'.  Otherwise, it"
	  csih_inform "will start automatically after the next reboot."
	fi
      else
	if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \
			      -a "-D" -y tcpip "${cygwin_env[@]}" \
			      -u "${run_service_as}" -w "${password}"
	then
	  /usr/bin/editrights -u "${run_service_as}" -a SeServiceLogonRight
	  echo
	  csih_inform "The sshd service has been installed under the '${run_service_as}'"
	  csih_inform "account.  To start the service now, call \`net start ${service_name}' or"
	  csih_inform "\`cygrunsrv -S ${service_name}'.  Otherwise, it will start automatically"
	  csih_inform "after the next reboot."
	fi
      fi

      if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1
      then
	check_service_files_ownership "${run_service_as}" || let ret+=$?
      else
	csih_error_recoverable "Installing sshd as a service failed!"
	let ++ret
      fi
    fi # user allowed us to install as service
  fi # service not yet installed
  return $ret
} # --- End of install_service --- #

# ======================================================================
# Main Entry Point
# ======================================================================

# Check how the script has been started.  If
#   (1) it has been started by giving the full path and
#       that path is /etc/postinstall, OR
#   (2) Otherwise, if the environment variable
#       SSH_HOST_CONFIG_AUTO_ANSWER_NO is set
# then set auto_answer to "no".  This allows automatic
# creation of the config files in /etc w/o overwriting
# them if they already exist.  In both cases, color
# escape sequences are suppressed, so as to prevent
# cluttering setup's logfiles.
if [ "$PROGDIR" = "/etc/postinstall" ]
then
  csih_auto_answer="no"
  csih_disable_color
  opt_force=yes
fi
if [ -n "${SSH_HOST_CONFIG_AUTO_ANSWER_NO}" ]
then
  csih_auto_answer="no"
  csih_disable_color
  opt_force=yes
fi

# ======================================================================
# Parse options
# ======================================================================
while :
do
  case $# in
  0)
    break
    ;;
  esac

  option=$1
  shift

  case "${option}" in
  -d | --debug )
    set -x
    csih_trace_on
    ;;

  -y | --yes )
    csih_auto_answer=yes
    opt_force=yes
    ;;

  -n | --no )
    csih_auto_answer=no
    opt_force=yes
    ;;

  -c | --cygwin )
    cygwin_value="$1"
    shift
    ;;

  -N | --name )
    service_name=$1
    shift
    ;;

  -p | --port )
    port_number=$1
    shift
    ;;

  -u | --user )
    user_account="$1"
    shift
    ;;
    
  -w | --pwd )
    password_value="$1"
    shift
    ;;

  --privileged )
    csih_FORCE_PRIVILEGED_USER=yes
    ;;

  *)
    echo "usage: ${progname} [OPTION]..."
    echo
    echo "This script creates an OpenSSH host configuration."
    echo
    echo "Options:"
    echo "  --debug  -d            Enable shell's debug output."
    echo "  --yes    -y            Answer all questions with \"yes\" automatically."
    echo "  --no     -n            Answer all questions with \"no\" automatically."
    echo "  --cygwin -c <options>  Use \"options\" as value for CYGWIN environment var."
    echo "  --name   -N <name>     sshd windows service name."
    echo "  --port   -p <n>        sshd listens on port n."
    echo "  --user   -u <account>  privileged user for service, default 'cyg_server'."
    echo "  --pwd    -w <passwd>   Use \"pwd\" as password for privileged user."
    echo "  --privileged           On Windows XP, require privileged user"
    echo "                         instead of LocalSystem for sshd service."
    echo
    exit 1
    ;;

  esac
done

# ======================================================================
# Action!
# ======================================================================

# Check for running ssh/sshd processes first. Refuse to do anything while
# some ssh processes are still running
if /usr/bin/ps -ef | /usr/bin/grep -q '/sshd\?$'
then
  echo
  csih_error "There are still ssh processes running. Please shut them down first."
fi

# Make sure the user is running in an administrative context
admin=$(/usr/bin/id -G | /usr/bin/grep -Eq '\<544\>' && echo yes || echo no)
if [ "${admin}" != "yes" ]
then
  echo
  csih_warning "Running this script typically requires administrator privileges!"
  csih_warning "However, it seems your account does not have these privileges."
  csih_warning "Here's the list of groups in your user token:"
  echo
  /usr/bin/id -Gnz | xargs -0n1 echo "   "
  echo
  csih_warning "This usually means you're running this script from a non-admin"
  csih_warning "desktop session, or in a non-elevated shell under UAC control."
  echo
  csih_warning "Make sure you have the appropriate privileges right now,"
  csih_warning "otherwise parts of this script will probably fail!"
  echo
  echo -e "${_csih_QUERY_STR} Are you sure you want to continue?  (Say \"no\" if you're not sure"
  if ! csih_request "you have the required privileges)"
  then
    echo
    csih_inform "Ok.  Exiting.  Make sure to switch to an administrative account"
    csih_inform "or to start this script from an elevated shell."
    exit 1
  fi
fi

echo

warning_cnt=0

# Create /var/log/lastlog if not already exists
if [ -e ${LOCALSTATEDIR}/log/lastlog -a ! -f ${LOCALSTATEDIR}/log/lastlog ]
then
  echo
  csih_error_multi "${LOCALSTATEDIR}/log/lastlog exists, but is not a file." \
		   "Cannot create ssh host configuration."
fi
if [ ! -e ${LOCALSTATEDIR}/log/lastlog ]
then
  /usr/bin/cat /dev/null > ${LOCALSTATEDIR}/log/lastlog
  if ! /usr/bin/chmod 644 ${LOCALSTATEDIR}/log/lastlog >/dev/null 2>&1
  then
    csih_warning "Can't set permissions on ${LOCALSTATEDIR}/log/lastlog!"
    let ++warning_cnt
  fi
fi

# Create /var/empty file used as chroot jail for privilege separation
csih_make_dir "${LOCALSTATEDIR}/empty" "Cannot create ${LOCALSTATEDIR}/empty directory."
if ! /usr/bin/chmod 755 "${LOCALSTATEDIR}/empty" >/dev/null 2>&1
then
  csih_warning "Can't set permissions on ${LOCALSTATEDIR}/empty!"
  let ++warning_cnt
fi

# generate missing host keys
csih_inform "Generating missing SSH host keys"
/usr/bin/ssh-keygen -A || let warning_cnt+=$?

# handle ssh_config
csih_install_config "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt
if /usr/bin/cmp "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/ssh_config" >/dev/null 2>&1
then
  if [ "${port_number}" != "22" ]
  then
    csih_inform "Updating ${SYSCONFDIR}/ssh_config file with requested port"
    echo "Host localhost" >> ${SYSCONFDIR}/ssh_config
    echo "    Port ${port_number}" >> ${SYSCONFDIR}/ssh_config
  fi
fi

# handle sshd_config
# make sure not to change the existing file
mod_before=""
if [ -e "${SYSCONFDIR}/sshd_config" ]
then
  mod_before=$(stat "${SYSCONFDIR}/sshd_config" | grep '^Modify:')
fi
csih_install_config "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt
mod_now=$(stat "${SYSCONFDIR}/sshd_config" | grep '^Modify:')
if ! /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1
then
  sshd_config_configured=yes
fi
if [ "${mod_before}" != "${mod_now}" ]
then
  sshd_strictmodes || let warning_cnt+=$?
  sshd_config_tweak || let warning_cnt+=$?
fi
#sshd_privsep || let warning_cnt+=$?
update_services_file || let warning_cnt+=$?
update_inetd_conf || let warning_cnt+=$?
install_service || let warning_cnt+=$?

echo
if [ $warning_cnt -eq 0 ]
then
  csih_inform "Host configuration finished. Have fun!"
else
  csih_warning "Host configuration exited with ${warning_cnt} errors or warnings!"
  csih_warning "Make sure that all problems reported are fixed,"
  csih_warning "then re-run ssh-host-config."
fi
exit $warning_cnt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Mon, Jan 28, 2019 at 11:39 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:

> Along these lines I have an OpenSSH patch in the loop which reverts
> the ssh-host-config script back to using the SYSTEM user, just as
> in the olden Windows XP days.  I'll send it upstream as soon as
> Cygwin 3.0 is officially released.  I attached the resulting
> ssh-host-config script to this mail, if you or anybody else want
> to test it.
> ...
> Super, thank you!  I guess I will role out a Cygwin test release in the
> next couple of days.

Hi Corinna,

Thank you. I wanted to point out that I have not had a chance to test
using a non-domain computer yet. I will try that scenario as well.

Bill

--
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

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart <bstewart@iname.com> wrote:

> Thank you. I wanted to point out that I have not had a chance to test
> using a non-domain computer yet. I will try that scenario as well.

Hi Corinna,

I unjoined a Windows 7 machine from the domain and tested as follows:

1. Ran setup and installed cygwin

2. Ran sshd-host-config and answered "no" to install as service

3. Installed service using this command line:

cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
"-D" -y "tcpip"

4. Renamed cygwin1.dll to a backup name and replaced with copy from
latest snapshot

When I try to start the service, I get error 1067 ("the process
terminated unexpectedly"). Event log states:

cygsshd: PID nnnn: starting service `cygsshd' failed: fork: 11,
Resource temporarily available

If I start bash elevated and run this:

/usr/sbin/sshd -d

It starts and listens on port 22 and I can connect.

Thoughts?

Bill

--
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

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Mon, Jan 28, 2019 at 2:49 PM Bill Stewart <bstewart@iname.com> wrote:

> I unjoined a Windows 7 machine from the domain and tested as follows:
>
> 1. Ran setup and installed cygwin
>
> 2. Ran sshd-host-config and answered "no" to install as service
>
> 3. Installed service using this command line:
>
> cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> "-D" -y "tcpip"
>
> 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> latest snapshot
>
> When I try to start the service, I get error 1067 ("the process
> terminated unexpectedly"). Event log states:
>
> cygsshd: PID nnnn: starting service `cygsshd' failed: fork: 11,
> Resource temporarily available
>
> If I start bash elevated and run this:
>
> /usr/sbin/sshd -d
>
> It starts and listens on port 22 and I can connect.

Also: If I revert cygwin1.dll to the 11/8/2018 version I am able to
start the service.

Bill

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

On Jan 28 14:49, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart <bstewart@iname.com> wrote:
> 
> > Thank you. I wanted to point out that I have not had a chance to test
> > using a non-domain computer yet. I will try that scenario as well.
> 
> Hi Corinna,
> 
> I unjoined a Windows 7 machine from the domain and tested as follows:
> 
> 1. Ran setup and installed cygwin
> 
> 2. Ran sshd-host-config and answered "no" to install as service
> 
> 3. Installed service using this command line:
> 
> cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> "-D" -y "tcpip"
> 
> 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> latest snapshot
> 
> When I try to start the service, I get error 1067 ("the process
> terminated unexpectedly"). Event log states:
> 
> cygsshd: PID nnnn: starting service `cygsshd' failed: fork: 11,
> Resource temporarily available
> 
> If I start bash elevated and run this:
> 
> /usr/sbin/sshd -d
> 
> It starts and listens on port 22 and I can connect.
> 
> Thoughts?

I can reproduce this on W7, while it works fine on W10.  Unfortunately I
haven't much time today and tomorrow but I'll try to get around to it
Thursday or Friday.

In the meantime, can you try the snapshots which one started to
introduce this issue?


Thanks and sorry for the hassle,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

On Jan 29 12:56, Corinna Vinschen wrote:
> On Jan 28 14:49, Bill Stewart wrote:
> > On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart <bstewart@iname.com> wrote:
> > 
> > > Thank you. I wanted to point out that I have not had a chance to test
> > > using a non-domain computer yet. I will try that scenario as well.
> > 
> > Hi Corinna,
> > 
> > I unjoined a Windows 7 machine from the domain and tested as follows:
> > 
> > 1. Ran setup and installed cygwin
> > 
> > 2. Ran sshd-host-config and answered "no" to install as service
> > 
> > 3. Installed service using this command line:
> > 
> > cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> > "-D" -y "tcpip"
> > 
> > 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> > latest snapshot
> > 
> > When I try to start the service, I get error 1067 ("the process
> > terminated unexpectedly"). Event log states:
> > 
> > cygsshd: PID nnnn: starting service `cygsshd' failed: fork: 11,
> > Resource temporarily available
> > 
> > If I start bash elevated and run this:
> > 
> > /usr/sbin/sshd -d
> > 
> > It starts and listens on port 22 and I can connect.
> > 
> > Thoughts?
> 
> I can reproduce this on W7, while it works fine on W10.  Unfortunately I
> haven't much time today and tomorrow but I'll try to get around to it
> Thursday or Friday.
> 
> In the meantime, can you try the snapshots which one started to
> introduce this issue?

Never mind, I found the culprit.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Jan 29 13:12, Corinna Vinschen wrote:
> On Jan 29 12:56, Corinna Vinschen wrote:
> > On Jan 28 14:49, Bill Stewart wrote:
> > > On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart <bstewart@iname.com> wrote:
> > > 
> > > > Thank you. I wanted to point out that I have not had a chance to test
> > > > using a non-domain computer yet. I will try that scenario as well.
> > > 
> > > Hi Corinna,
> > > 
> > > I unjoined a Windows 7 machine from the domain and tested as follows:
> > > 
> > > 1. Ran setup and installed cygwin
> > > 
> > > 2. Ran sshd-host-config and answered "no" to install as service
> > > 
> > > 3. Installed service using this command line:
> > > 
> > > cygrunsrv -I cygsshd -d "Cygwin SSH Service" -p "/usr/sbin/sshd" -a
> > > "-D" -y "tcpip"
> > > 
> > > 4. Renamed cygwin1.dll to a backup name and replaced with copy from
> > > latest snapshot
> > > 
> > > When I try to start the service, I get error 1067 ("the process
> > > terminated unexpectedly"). Event log states:
> > > 
> > > cygsshd: PID nnnn: starting service `cygsshd' failed: fork: 11,
> > > Resource temporarily available
> > > 
> > > If I start bash elevated and run this:
> > > 
> > > /usr/sbin/sshd -d
> > > 
> > > It starts and listens on port 22 and I can connect.
> > > 
> > > Thoughts?
> > 
> > I can reproduce this on W7, while it works fine on W10.  Unfortunately I
> > haven't much time today and tomorrow but I'll try to get around to it
> > Thursday or Friday.
> > 
> > In the meantime, can you try the snapshots which one started to
> > introduce this issue?
> 
> Never mind, I found the culprit.

Please try the snapshots I just uploaded to https://cygwin.com/snapshots/
They should fix the problem.  It turned out that I restricted the
permissions of processes too much for Windows 7.  The same code works
fine since Windows 8.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Tue, Jan 29, 2019 at 10:05 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:

> Please try the snapshots I just uploaded to https://cygwin.com/snapshots/
> They should fix the problem.  It turned out that I restricted the
> permissions of processes too much for Windows 7.  The same code works
> fine since Windows 8.

Tested updated DLL - working on Windows 7. Excellent - thank you!

Bill

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Jan 29 11:18, Bill Stewart wrote:
> On Tue, Jan 29, 2019 at 10:05 AM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> 
> > Please try the snapshots I just uploaded to https://cygwin.com/snapshots/
> > They should fix the problem.  It turned out that I restricted the
> > permissions of processes too much for Windows 7.  The same code works
> > fine since Windows 8.
> 
> Tested updated DLL - working on Windows 7. Excellent - thank you!
> 
> Bill

Thanks a lot for testing,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

sshd permits logon using disabled user?

[Bill Stewart]

I am running Windows 10 (1803) and experimenting with sshd installed as a
Windows service.

The computer is a domain member. I created a local computer account for
testing.

I created host keys and a public/private key pair to use to log on the user.

This works, except I notice that if I disable the Windows user account, I
can still log on using ssh using that account.

In the shell, logged on as the disabled user, the 'whoami' command returns
the name of the disabled user.

This seems unexpected and not good.

Why does sshd allow logon for a disabled user?

Thanks

Bill

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

On Jan 24 06:28, Bill Stewart wrote:
> I am running Windows 10 (1803) and experimenting with sshd installed as a
> Windows service.
> 
> The computer is a domain member. I created a local computer account for
> testing.
> 
> I created host keys and a public/private key pair to use to log on the user.
> 
> This works, except I notice that if I disable the Windows user account, I
> can still log on using ssh using that account.
> 
> In the shell, logged on as the disabled user, the 'whoami' command returns
> the name of the disabled user.
> 
> This seems unexpected and not good.
> 
> Why does sshd allow logon for a disabled user?

Because the underlying Cygwin function responsible for changing the user
account only checks if the account exists.  It does not check for any of
the flags in the user DB.  Yet.

I pushed a patch to disallow changing the user account to a disabled or
locked out account.

I just uploaded new developer snapshots containing this change to
https://cygwin.com/snapshots/

Please give them a try.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Stefan Baur]

[-- Attachment #1.1: Type: text/plain, Size: 1280 bytes --]

Am 24.01.19 um 16:45 schrieb Corinna Vinschen:
>> In the shell, logged on as the disabled user, the 'whoami' command returns
>> the name of the disabled user.
>>
>> This seems unexpected and not good.
>>
>> Why does sshd allow logon for a disabled user?
> Because the underlying Cygwin function responsible for changing the user
> account only checks if the account exists.  It does not check for any of
> the flags in the user DB.  Yet.
> 
> I pushed a patch to disallow changing the user account to a disabled or
> locked out account.

I would like to point out that on Linux, you can disable an account's
password ("password -l username" / "usermod -L username"), and still log
in using an SSH key pair.  This is intentional and different to
disabling an account entirely ("usermod -e 1 username" combined with the
above).

So I guess, the question is if there's a way to make Cygwin act similar
to this - maybe if you can tell disabled vs. locked out apart, allow SSH
key pair logins when locked out, but not when disabled?

Kind Regards,
Stefan Baur


-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Jan 24 16:51, Stefan Baur wrote:
> Am 24.01.19 um 16:45 schrieb Corinna Vinschen:
> >> In the shell, logged on as the disabled user, the 'whoami' command returns
> >> the name of the disabled user.
> >>
> >> This seems unexpected and not good.
> >>
> >> Why does sshd allow logon for a disabled user?
> > Because the underlying Cygwin function responsible for changing the user
> > account only checks if the account exists.  It does not check for any of
> > the flags in the user DB.  Yet.
> > 
> > I pushed a patch to disallow changing the user account to a disabled or
> > locked out account.
> 
> I would like to point out that on Linux, you can disable an account's
> password ("password -l username" / "usermod -L username"), and still log
> in using an SSH key pair.  This is intentional and different to
> disabling an account entirely ("usermod -e 1 username" combined with the
> above).
> 
> So I guess, the question is if there's a way to make Cygwin act similar
> to this - maybe if you can tell disabled vs. locked out apart, allow SSH
> key pair logins when locked out, but not when disabled?

Being disabled and being locked out are two different flags, so this
can be recognized from each other.  A disabled account is a an account
which is explicitely disabled in the user DB.  A locked out account in
Windows is to my understanding an account which has unsuccessfully tried
to login multiple times so the account is locked for security reasons,
until an admin unlocks it.

Right now, with the patch I just pushed, both types, explicitely disabled
or locked out" are refused.

I think refusing an account manually and deliberately disabled by an
admin makes lots of sense.

I'm not so sure about locked out accounts.  THis might need some
discussion.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Stefan Baur]

[-- Attachment #1.1: Type: text/plain, Size: 1105 bytes --]

Am 24.01.19 um 16:59 schrieb Corinna Vinschen:
> I think refusing an account manually and deliberately disabled by an
> admin makes lots of sense.
> 
> I'm not so sure about locked out accounts.  THis might need some
> discussion.

It's been a while since I did Windows administration, so I can't really
make a recommendation here ... BUT:

If an admin can lock out an account (separately from disabling it
entirely), say, by setting an initial password, checking the "user must
change password on first login", and also checking "user is not allowed
to change password" simultaneously (if that's possible), or, say, by
just setting a random password without telling it to anyone ever,
followed by firing so many login attempts at the account that it gets
locked out, then telling them apart and treating locked out accounts
differently would make sense, IMO.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On Jan 24 17:16, Stefan Baur wrote:
> Am 24.01.19 um 16:59 schrieb Corinna Vinschen:
> > I think refusing an account manually and deliberately disabled by an
> > admin makes lots of sense.
> > 
> > I'm not so sure about locked out accounts.  THis might need some
> > discussion.
> 
> It's been a while since I did Windows administration, so I can't really
> make a recommendation here ... BUT:
> 
> If an admin can lock out an account (separately from disabling it
> entirely), say, by setting an initial password, checking the "user must
> change password on first login", and also checking "user is not allowed
> to change password" simultaneously (if that's possible), or, say, by
> just setting a random password without telling it to anyone ever,
> followed by firing so many login attempts at the account that it gets
> locked out, then telling them apart and treating locked out accounts
> differently would make sense, IMO.

This description sounds extremly artificial to me.  We should work under
the assumption that the admin is the good guy.  Usually a user locks
itself out, or is locked out by a malicious login attempt.  The admin
can only define rules for locking out, other than that she can only
remove the "account locked" flag.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Stefan Baur]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

Am 24.01.19 um 17:36 schrieb Corinna Vinschen:
>> If an admin can lock out an account (separately from disabling it
>> entirely), say, by setting an initial password, checking the "user must
>> change password on first login", and also checking "user is not allowed
>> to change password" simultaneously (if that's possible), or, say, by
>> just setting a random password without telling it to anyone ever,
>> followed by firing so many login attempts at the account that it gets
>> locked out, then telling them apart and treating locked out accounts
>> differently would make sense, IMO.

> This description sounds extremly artificial to me.

> We should work under
> the assumption that the admin is the good guy.

Uh, where did I imply anything else?


>  Usually a user locks
> itself out, or is locked out by a malicious login attempt.  The admin
> can only define rules for locking out, other than that she can only
> remove the "account locked" flag.

The methods listed above, well, at least the "brute force" one, would
work for intentionally creating an account that is locked out, but not
disabled - as a good guy admin.

And the reason for doing so would be the same as running "passwd -l
username" on Linux - You don't want your users to log in with a
password, because you consider that too insecure - instead, you want
them to use the (hopefully passphrase-protected) SSH key file.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: sshd permits logon using disabled user?

[Andrey Repin]

Greetings, Stefan Baur!

> If an admin can lock out an account (separately from disabling it
> entirely), say, by setting an initial password, checking the "user must
> change password on first login", and also checking "user is not allowed
> to change password" simultaneously (if that's possible),

Unfortunately, that's not possible.


-- 
With best regards,
Andrey Repin
Saturday, January 26, 2019 22:01:42

Sorry for my terrible english...


--
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

Re: sshd permits logon using disabled user?

[Bill Stewart]

Hello Corinna,

I performed the following steps:

1. Downloaded cygwin-20190124.tar.xz
2. Extracted it
3. Stopped sshd
4. Renamed existing /bin/cygwin1.dll to cygwin1-20181108.dll
5. Copied cygwin1.dll from download to /bin
6. Started sshd

Did I miss anything?

It still allows logon with disabled account.

Thanks,

Bill


On Thu, Jan 24, 2019 at 8:45 AM Corinna Vinschen <corinna-cygwin@cygwin.com>
wrote:

> On Jan 24 06:28, Bill Stewart wrote:
> > I am running Windows 10 (1803) and experimenting with sshd installed as a
> > Windows service.
> >
> > The computer is a domain member. I created a local computer account for
> > testing.
> >
> > I created host keys and a public/private key pair to use to log on the
> user.
> >
> > This works, except I notice that if I disable the Windows user account, I
> > can still log on using ssh using that account.
> >
> > In the shell, logged on as the disabled user, the 'whoami' command
> returns
> > the name of the disabled user.
> >
> > This seems unexpected and not good.
> >
> > Why does sshd allow logon for a disabled user?
>
> Because the underlying Cygwin function responsible for changing the user
> account only checks if the account exists.  It does not check for any of
> the flags in the user DB.  Yet.
>
> I pushed a patch to disallow changing the user account to a disabled or
> locked out account.
>
> I just uploaded new developer snapshots containing this change to
> https://cygwin.com/snapshots/
>
> Please give them a try.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
>

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On Jan 24 09:48, Bill Stewart wrote:
> Hello Corinna,
> 
> I performed the following steps:
> 
> 1. Downloaded cygwin-20190124.tar.xz
> 2. Extracted it
> 3. Stopped sshd
> 4. Renamed existing /bin/cygwin1.dll to cygwin1-20181108.dll
> 5. Copied cygwin1.dll from download to /bin
> 6. Started sshd
> 
> Did I miss anything?

No, I did.

> It still allows logon with disabled account.

I should have tested pubkey auth as well but as it was I just tested
with pathword auth.  These methods take slightly different paths in
Cygwin when trying to switch the user account.

I pushed another patch and created new snapshots in the same location
https://cygwin.com/snapshots/.


HTH,
Corinna


> 
> Thanks,
> 
> Bill
> 
> 
> On Thu, Jan 24, 2019 at 8:45 AM Corinna Vinschen <corinna-cygwin@cygwin.com>
> wrote:
> 
> > On Jan 24 06:28, Bill Stewart wrote:
> > > I am running Windows 10 (1803) and experimenting with sshd installed as a
> > > Windows service.
> > >
> > > The computer is a domain member. I created a local computer account for
> > > testing.
> > >
> > > I created host keys and a public/private key pair to use to log on the
> > user.
> > >
> > > This works, except I notice that if I disable the Windows user account, I
> > > can still log on using ssh using that account.
> > >
> > > In the shell, logged on as the disabled user, the 'whoami' command
> > returns
> > > the name of the disabled user.
> > >
> > > This seems unexpected and not good.
> > >
> > > Why does sshd allow logon for a disabled user?
> >
> > Because the underlying Cygwin function responsible for changing the user
> > account only checks if the account exists.  It does not check for any of
> > the flags in the user DB.  Yet.
> >
> > I pushed a patch to disallow changing the user account to a disabled or
> > locked out account.
> >
> > I just uploaded new developer snapshots containing this change to
> > https://cygwin.com/snapshots/
> >
> > Please give them a try.
> >
> >
> > Thanks,
> > Corinna
> >
> > --
> > Corinna Vinschen
> > Cygwin Maintainer
> >
> 
> --
> 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

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Thu, Jan 24, 2019 at 1:23 PM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:

> I should have tested pubkey auth as well but as it was I just tested
> with pathword auth.  These methods take slightly different paths in
> Cygwin when trying to switch the user account.
>
> I pushed another patch and created new snapshots in the same location
> https://cygwin.com/snapshots/.

Just tested. Working now.

This is definitely the correct behavior IMO.

Thank you!

Bill

--
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

Re: sshd permits logon using disabled user?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Jan 24 13:36, Bill Stewart wrote:
> On Thu, Jan 24, 2019 at 1:23 PM Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> 
> > I should have tested pubkey auth as well but as it was I just tested
> > with pathword auth.  These methods take slightly different paths in
> > Cygwin when trying to switch the user account.
> >
> > I pushed another patch and created new snapshots in the same location
> > https://cygwin.com/snapshots/.
> 
> Just tested. Working now.
> 
> This is definitely the correct behavior IMO.
> 
> Thank you!

Thanks for testing,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sshd permits logon using disabled user?

[Bill Stewart]

Corinna Vinschen wrote:

> This description sounds extremly artificial to me.  We should work under
the
> assumption that the admin is the good guy.  Usually a user locks itself
out,
> or is locked out by a malicious login attempt.  The admin can only define
> rules for locking out, other than that she can only remove the "account
> locked" flag.

This is correct.

From a Windows perspective, "disabled" (UF_ACCOUNTDISABLE) means "account
cannot be used to log on," and "locked out" (UF_LOCKOUT) means "there were
too many bad password attempts, so the account is locked and cannot be used
to log on at this time." The administrator can specify whether the
UF_LOCKOUT duration is indefinite (this is usually not recommended, because
this can be used for DoS) or not.

Only an administrator (or a user with appropriate permissions) can set or
clear UF_ACCOUNTDISABLE. It is used to prevent _any_ use of the account.

UF_LOCKOUT is _only_ set by bad password attempts (the number of bad
attempts is set by policy) and is not really intended to be used for any
other purpose. UF_LOCKOUT can be cleared by an administrator (or user with
appropriate permissions), or the system can clear it automatically after
some duration (specified by policy), or it can be indefinite (although, as
previously noted, this is not usually recommended).

If you want to have an account that does not require a password, there is a
separate flag for that - PASSWD_NOTREQD - although setting this may be
prohibited by policy.

So basically Corinna's idea is correct: If UF_ACCOUNTDISABLE or UF_LOCKOUT
are set, the account should not allow logon.

Regards,

Bill

--
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

Re: sshd permits logon using disabled user?

[Stefan Baur]

Am 24.01.19 um 18:52 schrieb Bill Stewart:
> If you want to have an account that does not require a password, there is a
> separate flag for that - PASSWD_NOTREQD - although setting this may be
> prohibited by policy.

That sounds like the total opposite - allowing login without a password.

Now, if there was a flag PASSWD_NOTPERMITTED or something like that,
then we'd be able to emulate what can be done on Linux with "passwd -l
username" and an ssh key file.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

--
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

Re: sshd permits logon using disabled user?

[Bill Stewart]

On Thu, Jan 24, 2019 at 10:58 AM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:

That sounds like the total opposite - allowing login without a password.
>
> Now, if there was a flag PASSWD_NOTPERMITTED or something like that,
> then we'd be able to emulate what can be done on Linux with "passwd -l
> username" and an ssh key file.
>

You are correct; "password not required" != "password not permitted."

I don't think Windows natively supports password-free logons using only key
files (but I might be wrong about that).

In any case, I'm not sure it's needed to support this scenario. Just set a
very long/random/complex password on the account.

Regards,

Bill

--
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

Re: sshd permits logon using disabled user?

[Wayne Davison]

On Thu, Jan 24, 2019 at 10:13 AM Bill Stewart wrote:
> I don't think Windows natively supports password-free logons using only key
> files (but I might be wrong about that).

Don't forget that sshd_config fully supports disabling passwords.  You
can turn a password off for a single user via:

Match User foobar
    PasswordAuthentication no

Or set the "PasswordAuthentication no" as the default for all users.

..wayne..

--
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

Re: sshd permits logon using disabled user?

[Stefan Baur]

Am 24.01.19 um 20:17 schrieb Wayne Davison:
>> I don't think Windows natively supports password-free logons using only key
>> files (but I might be wrong about that).
> Don't forget that sshd_config fully supports disabling passwords.  You
> can turn a password off for a single user via:
> 
> Match User foobar
>     PasswordAuthentication no
> 
> Or set the "PasswordAuthentication no" as the default for all users.

Yes, but that will still allow the user to log in with their password
when they have access to the local screen and keyboard, or the machine
is reachable via RDP or CIFS, for example.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

--
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

Re: sshd permits logon using disabled user?

[Andrey Repin]

Greetings, Bill Stewart!

> Only an administrator (or a user with appropriate permissions) can set or
> clear UF_ACCOUNTDISABLE. It is used to prevent _any_ use of the account.

I would raise a correction, which is immaterial for Cygwin perspective.
Disabled accounts may still be used for internal/maintenance purposes.
I.e. a disabled Administrator account won't prevent invocation of a database
recovery procedure.


-- 
With best regards,
Andrey Repin
Saturday, January 26, 2019 22:13:54

Sorry for my terrible english...


--
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