Re: Daily insecurity output on valid users using key with valid shell and without password.
Hi Stuart, The counting to 13 was actually a sarcastic joke. (: But thanks never the less. Daniel On 7/1/18 5:54 PM, Stuart Henderson wrote: > On 2018-07-01, Daniel Ouellet wrote: >> Ha the old man page. >> >> Not good to read to quickly. (: >> >> Sorry for the noise. >> >> Now I just need to learn to count up to 13. > > Edit in vi, '13i*^[' or '13i*' > >
Re: Daily insecurity output on valid users using key with valid shell and without password.
On 2018-07-01, Daniel Ouellet wrote: > Ha the old man page. > > Not good to read to quickly. (: > > Sorry for the noise. > > Now I just need to learn to count up to 13. Edit in vi, '13i*^[' or '13i*'
Re: Daily insecurity output on valid users using key with valid shell and without password.
Set VERBOSESTATUS to 0 in /etc/daily.local Source: absolute openbsd 2nd edition, chapter 15 "System Maintenance" Havent done it myself but I hope its a good clue! On Sun, 1 Jul 2018, 8:47 pm Remco, wrote: > Op 07/01/18 om 19:22 schreef Daniel Ouellet: > > I find this annoying and sometime I over look this because I always get > > the example: > > > > == > > Running security(8): > > > > Checking the /etc/master.passwd file: > > Login share is off but still has a valid shell and alternate access > files in > >home directory are still readable. > > Login xxx is off but still has a valid shell and alternate access files > in > >home directory are still readable. > > = > > > > Is there a better or different way to do this? > > > > I always disable the login password on users with * oppose to password > > in the master.passwd file after keys are installed as I DO NOT want to > > allow login password when ssh keys are use, but still get the above > > warning daily on multiples servers & users. > > > > The Running security(8): is nice as you see possible changes done by sys > > admin and you get the feedback, but getting daily warning for the same > > things sometime will get overlook because of noise. > > > > Is there a better way to disable login and not get these warning for ssh > > key users and keep the valid idea and use of the cronjob as is? > > > > Daniel > > > > > > I think you need to use 13 asterisks for the password, passwd(5) has a > brief mentioning of this. > >
Re: Daily insecurity output on valid users using key with valid shell and without password.
Ha the old man page. Not good to read to quickly. (: Sorry for the noise. Now I just need to learn to count up to 13. Daniel 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. On 7/1/18 2:44 PM, Remco wrote: > Op 07/01/18 om 19:22 schreef Daniel Ouellet: >> I find this annoying and sometime I over look this because I always get >> the example: >> >> == >> Running security(8): >> >> Checking the /etc/master.passwd file: >> Login share is off but still has a valid shell and alternate access >> files in >> home directory are still readable. >> Login xxx is off but still has a valid shell and alternate access >> files in >> home directory are still readable. >> = >> >> Is there a better or different way to do this? >> >> I always disable the login password on users with * oppose to password >> in the master.passwd file after keys are installed as I DO NOT want to >> allow login password when ssh keys are use, but still get the above >> warning daily on multiples servers & users. >> >> The Running security(8): is nice as you see possible changes done by sys >> admin and you get the feedback, but getting daily warning for the same >> things sometime will get overlook because of noise. >> >> Is there a better way to disable login and not get these warning for ssh >> key users and keep the valid idea and use of the cronjob as is? >> >> Daniel >> >> > > I think you need to use 13 asterisks for the password, passwd(5) has a > brief mentioning of this.
Re: Daily insecurity output on valid users using key with valid shell and without password.
Op 07/01/18 om 19:22 schreef Daniel Ouellet: I find this annoying and sometime I over look this because I always get the example: == Running security(8): Checking the /etc/master.passwd file: Login share is off but still has a valid shell and alternate access files in home directory are still readable. Login xxx is off but still has a valid shell and alternate access files in home directory are still readable. = Is there a better or different way to do this? I always disable the login password on users with * oppose to password in the master.passwd file after keys are installed as I DO NOT want to allow login password when ssh keys are use, but still get the above warning daily on multiples servers & users. The Running security(8): is nice as you see possible changes done by sys admin and you get the feedback, but getting daily warning for the same things sometime will get overlook because of noise. Is there a better way to disable login and not get these warning for ssh key users and keep the valid idea and use of the cronjob as is? Daniel I think you need to use 13 asterisks for the password, passwd(5) has a brief mentioning of this.
Re: Daily insecurity output on valid users using key with valid shell and without password.
>From 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. I believe security(8) will stop barking about these accounts if you set the encrypted password to 13 asterisks, instead of just one. Sorry for top post. Gmail gets squirrelly sometimes when I try to properly respond in body. On Sun, Jul 1, 2018 at 12:22 PM, Daniel Ouellet wrote: > I find this annoying and sometime I over look this because I always get > the example: > > == > Running security(8): > > Checking the /etc/master.passwd file: > Login share is off but still has a valid shell and alternate access files > in > home directory are still readable. > Login xxx is off but still has a valid shell and alternate access files in > home directory are still readable. > = > > Is there a better or different way to do this? > > I always disable the login password on users with * oppose to password > in the master.passwd file after keys are installed as I DO NOT want to > allow login password when ssh keys are use, but still get the above > warning daily on multiples servers & users. > > The Running security(8): is nice as you see possible changes done by sys > admin and you get the feedback, but getting daily warning for the same > things sometime will get overlook because of noise. > > Is there a better way to disable login and not get these warning for ssh > key users and keep the valid idea and use of the cronjob as is? > > Daniel > >
Daily insecurity output on valid users using key with valid shell and without password.
I find this annoying and sometime I over look this because I always get the example: == Running security(8): Checking the /etc/master.passwd file: Login share is off but still has a valid shell and alternate access files in home directory are still readable. Login xxx is off but still has a valid shell and alternate access files in home directory are still readable. = Is there a better or different way to do this? I always disable the login password on users with * oppose to password in the master.passwd file after keys are installed as I DO NOT want to allow login password when ssh keys are use, but still get the above warning daily on multiples servers & users. The Running security(8): is nice as you see possible changes done by sys admin and you get the feedback, but getting daily warning for the same things sometime will get overlook because of noise. Is there a better way to disable login and not get these warning for ssh key users and keep the valid idea and use of the cronjob as is? Daniel
