On Sun, May 19, 2019 at 12:14 PM Kevin Fenzi <ke...@scrye.com> wrote: > > On 5/19/19 8:48 AM, Christopher wrote: > > On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi <ke...@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. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
