Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

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

 



On 5/19/19 8:48 AM, Christopher wrote:
> On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
>>
>> On 5/17/19 5:23 AM, Stephen Gallagher wrote:
>>
>> ...snip...
>>
>>> 3) Force Anaconda to require the creation of a non-root user that is a
>>> member of the `wheel` group, so that this user can be used to SSH in
>>> and administer the system. Essentially, remove the root user creation
>>> spoke as an option from the interactive install.
>>
>> So, this is basically the old cloud-init makes a user that can sudo to
>> root thing. Can anyone explain in small words how this is more secure?
>>
> 
> If you've ever examined your audit logs for failed authentications,
> you'll notice the difference is substantial. The root user is under
> non-stop attack over ssh, by countless bots and malicious users. Other
> users are not so frequently targeted. The attack surface is
> dramatically reduced when disabling access for the the root user over
> ssh, and replacing that with a different user. This is not perfect
> security, but it reduces the attack surface that can be automatically
> targeted by automated attack tools.

I guess this is not the old cloud-init thing, since the proposed action
here leaves the non-root user with a password. In cloud-init land,
there's no passwords, the non-root user has a key. In that case I cannot
see any difference between root having a key and the non-root user
having a key and being able to sudo to root.

One objection to this proposal last time this came up was that the
device was going to join a ipa domain or the like, and a local non-root
user was not desired. I suppose in that case they could delete the user
after the initial setup.

> 
>> I mean, in this case the attacker would need to guess the username in
>> addition to the password (where in the cloud cause this is known), but
>> otherwise why not just keep root password access ?
>>
> 
> The other user is not necessarily known, even in the cloud case. At
> least on Amazon EC2, cloud-init can be used to parse user-data passed
> in to add a user dynamically at launch time, rather than have the
> default user well-known in the cloud image.

Sure, and it can also not make one and leave root, but in practice I
don't know too many people that do this. If you looked for 'fedora',
'centos' and 'rhel' and 'ubuntu' you would get most of them.

As noted, the cloud-init case has no passwords, only keys.

> 
>> I always found that cloud default anoying and useless and haven't yet
>> seen a good argument to not do it.
> 
> Cloud default users are, from my limited experience on AWS and looking
> at my own audit logs, are nearly as often targeted by attackers as the
> root user. So, I find these defaults annoying, too. The secure
> position shouldn't be to admit defeat and leave password-based login
> for the root user open on SSH... the secure position should be to
> immediately create a new user during setup (either via kickstart,
> anaconda, or cloud-init) that isn't a built-in default user (either
> built-in to the OS, as "root" is, or built-in to the cloud image, as
> "fedora" and "centos", etc. users are).

If I am using ssh keys, I don't care about people trying to brute force
passwords. Forcing the root account closed and having to use a 'user'
account to login and sudo just seems like a pointless hoop.

root account with key -> login as root with key
user account with key / root locked -> login as user, sudo

Thats another shell running, another sudo process, etc.

Anyhow, thats not this case, so I should move along.

At this point I think I am ok with the change, but I would really like
to hear from some folks that didn't like it the last time it was
proposed to see if we missed any cases.

kevin


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux