On Jan 29 11:18, Bill Stewart wrote:
> On Tue, Jan 29, 2019 at 10:05 AM Corinna Vinschen
> 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
On Tue, Jan 29, 2019 at 10:05 AM Corinna Vinschen
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.
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 wrote:
> > >
> > > > Thank you. I wanted to point out that I have not had a chance to test
> > > > using a non-domain
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 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.
> >
>
On Jan 28 14:49, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart 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
On Mon, Jan 28, 2019 at 2:49 PM Bill Stewart 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
On Mon, Jan 28, 2019 at 1:14 PM Bill Stewart 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
On Mon, Jan 28, 2019 at 11:39 AM Corinna Vinschen
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
On Jan 28 10:18, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 9:52 AM Corinna Vinschen
> wrote:
> >
> > On Jan 28 08:02, Bill Stewart wrote:
> > > On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
> > > wrote:
> > >
> > > > Can you please test again with the latest snapshot from
> > > >
On Mon, Jan 28, 2019 at 9:52 AM Corinna Vinschen
wrote:
>
> On Jan 28 08:02, Bill Stewart wrote:
> > On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
> > wrote:
> >
> > > Can you please test again with the latest snapshot from
> > > https://cygwin.com/snapshots/? The new S4U authentication
On Jan 28 08:02, Bill Stewart wrote:
> On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
> 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
On Mon, Jan 28, 2019 at 2:59 AM Corinna Vinschen
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
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
>>> wrote:
>>>
There are different paths to access and to completely disable the account
you
Bill,
On Jan 25 11:03, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
> 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
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
> > wrote:
> >
> >> There are different paths to access and to completely disable the account
> >> you need to close all of them. There are many reasons
On 25/01/2019 18:03, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
> 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
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
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
On Fri, Jan 25, 2019 at 10:48 AM Stephen Paul Carrier
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
On Fri, Jan 25, 2019 at 08:34:09AM -0700, Bill Stewart wrote:
> On Fri, Jan 25, 2019 at 3:36 AM Stefan Baur 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
On Jan 24 13:36, Bill Stewart wrote:
> On Thu, Jan 24, 2019 at 1:23 PM Corinna Vinschen
> 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.
>
On Fri, Jan 25, 2019 at 3:36 AM Stefan Baur 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
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
>
> 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
On Thu, Jan 24, 2019 at 1:23 PM Corinna Vinschen
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
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
>
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:
>
>
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:
On Thu, Jan 24, 2019 at 10:58 AM Stefan Baur 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
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,
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
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"
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
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
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
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
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
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
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
39 matches
Mail list logo
