We are not disabling root access entirely, you can log on local console or use su after loging with a normal user.
So a lot of sites have set up that you remotely kickstart a system and then ansible in as root with the rest of the configurations. It is the biggest reason we have been keeping this as active for a long time. You are breaking all those configs with a 'oh you can just login on a local console'. That kickstart may not have any of that.. and the last thing a sysadmin wants when they are building 4000 nodes somewhere is find out that they need to add another 20 steps to their post..
Make it a predefined kickstart thing they can do so all they have to do is add a line in it that says
ssh_remote --user=<account> --keyfile=<url> --yesIwantrootandIknowitsbad
and you have covered your bases. Turning off expected options in the name of security sounds great and easy.. and the one thing I have learned in computer security is that is the siren song which dashes your ship on the rocks of pissed off system administrators.
After installing server without the proposed changes (that could be great, but not needed) you can log in with the normal user and use su to scalate privileges and either change sshd_config or add a pubkey on authorized_keys.
Right now we will need a normal user to be able to access as root after a remote install, but it does not neccesary need to be part of wheel (I believe that su is not restricted)
Just a root user and not a regular one will finish with a box that is not accesible remotely and that could be a problem
On Fri, May 17, 2019 at 8:37 AM Martin Kolman <mkolman@redhat.com> wrote:
>
> On Fri, 2019-05-17 at 08:23 -0400, 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.
> The current policy during ineractive install is, one of (or both) must exists:
> - a root account that is not locked
> - a user in the wheel group
>
> This could be tweaked accordingly (eq. always require at least one user in the wheel
> group regardless of the state of the root account).
>
I might not have been clear in my original email. My point was mainly
that I want these problems identified, a solution agreed-upon and
added to the Change Proposal before it goes to a FESCo vote. I'd be
inclined to vote -1 without a plan in place to deal with this. This is
indeed probably the least-intrusive change we can make (and aligns us
a little closer to how other popular distros are doing things these
days), and if Anaconda team is willing to commit to doing that work
here, that would be great.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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