On Nov 22 15:33:04, [email protected] wrote:
> On Tue, Nov 21, 2017 at 1:50 AM, Jan Stary <[email protected]> wrote:
> > Running security(8):
> >
> > Checking the /etc/master.passwd file:
> > Login maxa is off but still has a valid shell and alternate access files
> > in
> > home directory are still readable.
> >
> >
> > According to master.passwd(5)
> >
> > login accounts not allowing password authentication but allowing
> > other authentication methods, for example public key
> > authentication,
> > conventionally have 13 asterisks in the password field.
> >
> > but adduser did not put 13 asterisks in the password field (just '*')
> > and security(8)'s check_passwd() seems to have no notion of
> > '13 asterisks in the password field' - the login is just considered 'off'
> > if $pwd !~ /^\$[0-9a-f]+\$/
> >
> > Is the info in master.passwd(5) still valid?
> > Should adduser put '*************' as the passwd for such accounts?
> > (I do see accounts with 13 asterisks for passwd, e.g. _postgresql.)
>
> The 13 asterisks trick does work.
Yes it does - changing the user's passwd to 13 asterisks with vipw
makes security(8) recognize it as such.
> length $pwd != 13 &&
Yes, that's what I missed. Thanks.
> It does make sense to me that adduser(8) should put in 13 asterisks
> instead of 1 but until now I have remained silent because I did not
> have any diff to submit.
>
> In the meantime I have been using vipw(8) to manually set the 13
> asterisks on the appropriate accounts. In my case I am using such
> accounts for remote backups via SSH, and I had the same issue with
> security notifications. I did not want to just ignore the messages
> because that leads to bad habits.
I believe now that it's intended: an account with a passwd of '*'
is not supposed to log in; if he is, like with a ssh key,
explicitly change it to '*************' with vipw.
Jan
