On 9/26/22 16:03, Antoine Jacoutot wrote: > On Mon, Sep 26, 2022 at 09:58:13PM +0200, Florian Obser wrote: >> Set the password hash to 13 * using vipw(8) or usermod -p. >> >> I wonder if we document that somewhere. > We do, in passwd(5). > > Similarly, login accounts not allowing password authentication but allowing other authentication methods, for example public key authentication, conventionally have 13 asterisks in the password field.
The relevant lines in security(8) at /usr/libexec/security > Line 103: length $pwd != 13 It doesn't seem like it is checking that it is 13 * specifically as opposed to just being 13 chars in width. Nor does the line in passwd(5) say anything about it being run in security(8), security(8) does not mention this check being done in its man page (at least not after I gave another cursory look at it). > Check the master.passwd(5) and group(5) files for syntax, empty passwords, partially closed accounts, suspicious UIDs, suspicious GIDs, and duplicate entries. Seems like updating that "conventionally have" to something more substantial or maybe the "partially closed accounts" to something else would be a good thing. >> On 26 September 2022 20:27:07 CEST, Federico Giannici <[email protected]> >> wrote: >>> I have a login that I want to be able to access only via ssh with a >>> certificate (in ~/.ssh/authorized_keys). >>> >>> >>> So I have disabled the password ('*') but left a valid shell. Something >>> like this in /etc/master.passwd: >>> >>> mylogin:*:1001:1001::0:0:My login:/home/mylogin:/bin/sh >>> >>> >>> But in this way every day a receive a mail with the following: >>> >>> Checking the /etc/master.passwd file: >>> Login mylogin is off but still has a valid shell and alternate access files >>> in home directory are still readable. >>> >>> >>> What is the supposed way to define an account without a password but with a >>> valid shell (to access via ssh with a certificate)? >>> >>> Thanks. >>> >> -- >> Sent from a mobile device. Please excuse poor formatting. >>
