openbsd: set_passwd should not unlock user

[goneri]

usermode -C no foo does not work on OpenBSD. Unlike NetBSD, we don't
actually need to unlock the user.

[igalic]

an account on OpenBSD is locked with usermod -Z and unlocked with usermod -U

or is this, again, specifically about password based logins over the network?

[goneri]

an account on OpenBSD is locked with usermod -Z and unlocked with usermod -U

or is this, again, specifically about password based logins over the network?

When you set a new password to a OpenBSD account, you unlock it at the same time because the * at the beginning of the password has been removed. usermod -Z will disable the account, in addition to the password, this is not what we want.
This being said, I'm not sure we can properly lock the password of a user on OpenBSD. We do usermod -C yes which should not work.

[raharper]

Looking at the manpage on NetBSD/OpenBSD it seems to me there is no direct command for locking the password itself and keeping the account active, which is what is needed.

It sounds like a common BSD lock_password() could be:

usermod -p *

However, that would drop the existing password; Other than manually inserting the '*' in to the
correct user's password field and removing it; I don't think it's supported.

[goneri]

When I build the NetBSD image, I do a usermod -C yes root to disable the root account. The root account password-based auth is disable, but we can still use a ssh key to login.
There is nothing like that for OpenBSD. I just need to set a new root password to be able to log in using a password.

This patch does not address the ability to lock an account on OpenBSD. It ensures we can set the password of an user.

[raharper]

I do a usermod -C yes root to disable the root account. The root
account password-based auth is disable, but we can still use a ssh
key to login.

My reading of the manpage suggest that the '-C yes' locks the account ;
does this not also prevent ssh login ?

 -C yes/no
             Enable user accounts to be temporary locked/closed.  The yes/no
             operand can be given as ``yes'' to lock the account or ``no'' to
             unlock the account.

OpenBSD seems the same.

-U  Unlock the account by removing the trailing ‘-’ from the user's shell
    and the ‘*’ prefix from the password. -U and -Z are mutually exclusive
    and cannot be used with -p.

-Z
    Lock the account by appending a ‘-’ to the user's shell and prefixing the
    password with ‘*’. -Z and -U are mutually exclusive and cannot be used
    with -p.

Can you confirm that "lock account" disables password entry but allows ssh
authorization on both NetBSD and OpenBSD?

The comments on this PR aren't clear about what locking passwd vs locking
account.

[goneri]

NetBSD

-C yes: password disabled: yes, account disabled (e.g: SSH): no. This is handy to disable the root account of a Cloud image.

OpenBSD

-Z: password disabled: yes, account disabled (e.g: SSH): yes. This goes beyond a classic password locking, as expected by Cloud-init.

Why this patch

Currently, NetBSD we silently re-enable the account if we set a password, this just in case the password auth was disabled. This to reproduce the behaviour of the other systems (including OpenBSD). This patch ensures we don't do that on OpenBSD.

[raharper]

OK. I'm sorry this has been difficult for me to grasp. Let me try again.

In NetBSD, the unlock happens when set_passwd() is called
and runs 'usermod -C no -p .

OpenBSD distro class reuses this method, however, the '-C no' is
not valid per the OpenBSD manpage on usermod.

So, drop the '-C no', create a new method for unlocking the password
and then override it in OpenBSD. That explains the patch as it is.

One follow up, the OpenBSD lock_passwd method uses:

usermod -p '*' name;

If this is run, how can one unlock the passwd?

[goneri]

If this is run, how can one unlock the passwd?

It's not a reversible operation, because we replace its hashed content with '*'. So to unlock the account, we need to set a new password.

[raharper]

If this is run, how can one unlock the passwd?

It's not a reversible operation, because we replace its hashed content with '*'. So to unlock the account, we need to set a new password.

Is this known to OpenBSD users? Should lock_passwd() be used on OpenBSD by default? Cloud-init defaults to locking passwords by default to encourage use of ssh. I wonder if we can just make a doc note that on OpenBSD, one cannot undo the locked password, rather one must set a new password instead? We can do that in a separate PR.

[raharper]

Thanks for helping me understand the changes in this PR.

[goneri]

If this is run, how can one unlock the passwd?

It's not a reversible operation, because we replace its hashed content with '*'. So to unlock the account, we need to set a new password.

Is this known to OpenBSD users? Should lock_passwd() be used on OpenBSD by default? Cloud-init defaults to locking passwords by default to encourage use of ssh. I wonder if we can just make a doc note that on OpenBSD, one cannot undo the locked password, rather one must set a new password instead? We can do that in a separate PR.

Is this specific to OpenBSD, I believe Linux has the same behaviour.

[raharper]

If this is run, how can one unlock the passwd?

It's not a reversible operation, because we replace its hashed content with '*'. So to unlock the account, we need to set a new password.

Is this known to OpenBSD users? Should lock_passwd() be used on OpenBSD by default? Cloud-init defaults to locking passwords by default to encourage use of ssh. I wonder if we can just make a doc note that on OpenBSD, one cannot undo the locked password, rather one must set a new password instead? We can do that in a separate PR.

Is this specific to OpenBSD, I believe Linux has the same behaviour.

It looks like Linux usermod(8) supports lock and unlock.

  -L, --lock
           Lock a user's password. This puts a '!' in front of the encrypted password, 
           effectively disabling the password. You can't use this option with -p or -U.

           Note: if you wish to lock the account (not only access with a password),
           you should also set the EXPIRE_DATE to 1.

  -U, --unlock
           Unlock a user's password. This removes the '!' in front of the encrypted password.
           You can't use this option with -p or -L.

           Note: if you wish to unlock the account (not only access with a password),
           you should also set the EXPIRE_DATE (for example to 99999, or to the EXPIRE
           value from /etc/default/useradd).

[goneri]

If this is run, how can one unlock the passwd?

It's not a reversible operation, because we replace its hashed content with '*'. So to unlock the account, we need to set a new password.

Is this known to OpenBSD users? Should lock_passwd() be used on OpenBSD by default? Cloud-init defaults to locking passwords by default to encourage use of ssh. I wonder if we can just make a doc note that on OpenBSD, one cannot undo the locked password, rather one must set a new password instead? We can do that in a separate PR.

Is this specific to OpenBSD, I believe Linux has the same behaviour.

It looks like Linux usermod(8) supports lock and unlock.

  -L, --lock
           Lock a user's password. This puts a '!' in front of the encrypted password, 
           effectively disabling the password. You can't use this option with -p or -U.

           Note: if you wish to lock the account (not only access with a password),
           you should also set the EXPIRE_DATE to 1.

  -U, --unlock
           Unlock a user's password. This removes the '!' in front of the encrypted password.
           You can't use this option with -p or -L.

           Note: if you wish to unlock the account (not only access with a password),
           you should also set the EXPIRE_DATE (for example to 99999, or to the EXPIRE
           value from /etc/default/useradd).

Ok TIL. Thanks.