2

From man passwd

-l, --lock
          This option is used to lock the password of specified account
          and it is available to root only. The locking is performed by rendering
          the encrypted password into an  invalid  string  (by
          prefixing  the  encrypted string with an !). Note that the
          account is not fully locked - the user can still log in by other means
          of authentication such as the ssh public key authentication.
          Use chage -E 0 user command instead for full account locking.

From man usermod

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

Both options put a ! at the very beginning of the password in the shadow file.

Why usermod doesn't warn about not locking for other kinds of authentications if it's supposed to do the same?

Is there anything else to have consideration with when locking an account between this two options?

1

The usermod man page on man7.org and the one on my Debian system does contain a warning to the same effect:

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

If it doesn't say that on some system, well, I suppose it just goes to show that not all documentation can be perfect. At least the text you quoted explicitly mentions it locks the "[the] user's password.", so a close reading can still hint that there's some limitation to it.


I don't think there's much else to consider there, both of the tools do the same thing and make the password (and only the password) unusable. Anything that doesn't use the password (su by a privileged user; sudo depending on the configuration; cron; SSH keys...) will still happily do their work as the password-locked user.

As noted in the passwd man page, making the account expired may work as a wider block. I think the expiration is checked by the PAM session modules, which usually called even if authentication doesn't go through PAM.

("Usually", because any privileged program could just change the user ID without regard to the account expiration either, if it was programmed to do that. But at least cron and sshd do start a PAM session, and thus do check the expiration.)


In any case, if you start locking user accounts, it might not be a bad idea to test that the locking works as expected (with a test account). Just because this would probably be one of those situations where you really don't want to leave holes open.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.