On Sun, May 19, 2019 at 12:14 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On 5/19/19 8:48 AM, Christopher wrote:
> On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>> On 5/17/19 5:23 AM, Stephen Gallagher wrote:
>>> 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.
In cloud-init land, the user can set a password by using their "sudo"
privileges, and can set it for the "root" user and for the "ec2puser"
or other cloud user. I don't think that Fedora should try to outsmart
all the different use cased cases for cloud deployment by selecting
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.
Yup, along with /etc/ssh/ssh_config, /etc/ssh/ssshd_config, and
$HOME/.ssh/config, and the way cloud-init blocks direct root SSH
logins, by manipulationg $HOME/.ssh/authorized_keys. There are too
many options to try and outsmart them via sshd_config policy.
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.
You forgot "ec2puser".
If I am using ssh keys, I don't care about people trying to brute
passwords. Forcing the root account closed and having to use a 'user'
account to login and sudo just seems like a pointless hoop.
It provides tracking of which user's credentials have been abused.
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.
Yes, and for precisely the reasons above.
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.
That seems a very thoughtful suggestion.