On 2/17/2016 3:31 PM, Tom Browder wrote:
> On Wed, Feb 17, 2016 at 9:33 AM, Jeremy T. Bouse
> <jeremy.bouse@undergrid.net> wrote:
>> Setting SSH "PermitRoot no" and "PasswordAuthentication no" are good
>> starts... I'd also check that "ChallengeResponseAuthentication no" is set as
>> well as some PAM modules will utilize it and be able to get around passwords
>> being entered as well as "UsePAM no"
> Okay.
>
>> I do agree locking the root password isn't advisable. As I use
>> configuration management/automation to handle my servers I simply set the
>> root password to generated password that only I know the algorithm to
>> reproduce it when I need to,
> Can you give more details on the process (at least generally)?
It's a technique I picked up from a past job... We took several pieces
of information we'd know about a machine and concatenated it together
with a delimiter character, then hashed it and cut it to length then
used that as the password. So it was then encrypted with the appropriate
password crypt routine for the host. If we needed the root password we
could regenerate it from the information but rarely needed it outside of
a DR situation.
>> but enable sudoers for all other 'root' access.
> Can one use that method and restrict use of "sudo su?"
You can restrict which commands can be executed and limit sudo to only
running certain commands at all. I don't use 'sudo su' as it's quite
redundant. When I do want a root shell I just do 'sudo -i' which I'm not
certain that can be restricted or not I'd have the RTFM on sudo to
investigate. Another thing I do on certain accounts is enable full input
and output logging so I can actually replay their sudo session in it's
entirety. I've had to do this before where we've been forced to give
sudo access to dev admins on a dev box and then they break things and
ask us to help them fix it. We grew tired of hearing "nothing" in
response to asking them what they changed, so we enabled the logging. We
use the same sudoers file site-wide as it's pushed out to all boxes.
>> I also go further by utilizing Duo Security as a MFA for SSH logins to
>> my servers for accounts authorized to log in.
> Hm, so you do allow some accounts password access?
Actually none of the user accounts have password access... All
access is via SSH identity keys that are pushed out via the config
management/automation process. Users can later add keys but the keys
managed via conf mgmt/automation are controlled exclusively from there
so they can be revoked and enforced.
> Thanks, Jeremy!
>
> Best,
>
> -Tom
>
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature