[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ssh



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


Reply to: