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 ?
On 18 Nov 2018, 19:50 +0800, Michael Howard <firstname.lastname@example.org>, wrote:
On 17/11/2018 04:28, Alan Taylor wrote:
Yes, it is normal. A user with /bin/false as his ahell should not be able to login. These days www-data has /bin/false too, which caught be out, until I changed it back.
I am getting that together to show you.
A question though - are you sure this is not normal behavior ?
Most of my research on the net (with caution I know) seems to suggest that ssh disconnection after authentication because of /bin/false is normal ?