On 11/19/2018 8:28 AM, Michael Howard wrote: > On 19/11/2018 02:46, Alan Taylor wrote: >> Thanks Mike, >> >> I was slowly coming to that conclusion ! >> What would be best practice regarding a password for that account >> (i.e. system account such as backuppc that needs ssh access but no >> shell access). >> >> If I create the user with bash as the shell, I seem to have a few >> options: >> 1) don’t set a password (i.e. no reference to password in the adduer >> command). The man page says this results in the password being >> “disabled”. What does this actually mean for security ? >> 2) use —disabled-password (same as 1 above ?) >> 3) the —disabled-password option appears to be only available on >> debian. Redhat derivatives only offer useradd which does not have this >> switch ? >> >> Which would be the most secure, while still allowing ssh access ? >> >> > > Don't get too hung up on it all. > > If the account needs login access then give it. Create or use an account > with a shell of your choice and a secure password. You don't need to > remember the password, as you are using keys, so it can be ridiculously > secure. A standard user cant do much harm if you don't give it any more > privileges than it needs. >
Some hints to better secure your setup: Locking the password of the named accound (1). In '/etc/ssh/sshd_config' using an 'match' condition (2) to only allow public key. Further restricting the allowd commands in authorized_keys file (3, Format of the Authorized Keys File). 1) http://man7.org/linux/man-pages/man1/passwd.1.html 2) https://linux.die.net/man/5/sshd_config 3) https://www.ssh.com/ssh/authorized_keys/openssh#sec-Format-of-the-Authorized-Keys-File Note that this e-mail is folded by my mailer. -- John Doe
