On Nov 22 15:33:04, kgo...@gmail.com wrote: > On Tue, Nov 21, 2017 at 1:50 AM, Jan Stary <h...@stare.cz> 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