This one time, at band camp, Justin Pryzby said:
> adduser has 2 options:
> |[--disabled-password] [--disabled-login] USER
> ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
>
> Internally, disabled-login seems to disable more than disabled-password:
> "disabled-password" => sub { $ask_passwd = 0 },
> "disabled-login" => sub { $disabled_login = 1; $ask_passwd = 0 },
>
> And the manpage is consistent with this interpretation:Correct so far. > So I expect disabled-password users to be able to login with RSA keys, and > disabled-login users to be completely disabled? Both of them accept RSA auth > over SSH. Is there some RSA auth that can happen locally?? All RSA auth happens 'locally', in the sense that the public key being offered has to be somewhere local for the key exchange to succeed. But this is a fairly obvious answer, so I'm not sure that's what you were really asking. > Is some broken login program supposed to be checking for * as a special case? > Are the 1-character flags [x!*] supposed to act differently? > > Similar bugs include 389183. And as you'll note, they all run into the same limitation you're finding. It's a fundamental flaw in the overloading of the meaning of the field. According to shadow(5): "If the password field contains some string that is not valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in, subject to pam(7)." I am not sure how this is a bug in adduser, though. All that adduser can do is handle values available to us through standard tools like usermod and passwd. It explicitly does not rewrite your pam stack or your sshd config. But I'm assuming you know that as well, so how are you hoping to see this resolved? -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
