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. Look at security(8) again, but one line higher: length $pwd != 13 && 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. -ken
