On Mon, Feb 25, 2019 at 08:50:18AM -0600, Adam Thompson wrote: > Hi, > I'm getting daily insecurity (i.e. security(8)) nags about > userids that are off but still have a valid shell and access > files. (Specifically, I'm getting the nag from > check_access_files() in /usr/libexec/security.) > > Since ports (at least in my experience) regularly creates > userids that will trigger this warning, what's the "best" way to > disable the warning? I'm reluctant to mess with permissions on > directories created by packages, but maybe that's the best way? > > Otherwise, it looks like I can disable the warning by setting a > password on the userid in question. > > However, that leads to the question: what if I don't *want* a > password on the account, because it's supposed to be a > SFTP-only, public-key-authentication-only account, but still > needs to be readable and needs a valid shell for various cron > jobs to be happy? If I'm following the logic correctly, one of > the warnings I'm getting is for ~/.ssh being readable on a > userid with no password - exactly the scenario I just mentioned. > But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? > > The most distasteful option is to hack /usr/libexec/security to > ignore certain userids, but ... it's there for a reason. > > The cleanest example I have right now from ports is _rancid, > created by the rancid package, and triggered by the existence of > ~_rancid/.ssh with S_IRUSR (u+r) permissions. > > Suggestions / advice? > > Thanks, > -Adam >
Use vipw to put 13 * in the password field >From passwd(5) The password field is the encrypted form of the password. If the password field is empty, no password will be required to gain access to the machine. This is almost invariably a mistake. By convention, accounts that are not intended to be logged in to (e.g. bin, daemon, sshd) only contain a single asterisk in the password field. Note that there is nothing special about ‘*’, it is just one of many characters that cannot occur in a valid encrypted password (see crypt(3)). 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. Because master.passwd contains the encrypted user passwords, it should not be readable by anyone without appropriate privileges.
