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:
>>
>> ...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.
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
sshd_config.
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
force
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.
kevin
That seems a very thoughtful suggestion.