If someone is remotely installing with kickstart on a non interactive way I assume they have enough knownledge to modify that ks to either add a pubkey to root or modify sshd_config
Anyhow yeah, would be great to help making this easy with a ks default, or macros Stephen John Smoogen <smo...@gmail.com> igorleak hau idatzi zuen (2019 mai. 17, or. 17:10): > > > On Fri, 17 May 2019 at 10:41, Julen Landa Alustiza <ju...@zokormazo.info> > wrote: > >> 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 >> >> Stephen Gallagher <sgall...@redhat.com> igorleak hau idatzi zuen (2019 >> mai. 17, or. 16:20): >> >>> On Fri, May 17, 2019 at 8:37 AM Martin Kolman <mkol...@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-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 >>> >> _______________________________________________ >> 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 >> > > > -- > Stephen J Smoogen. > > _______________________________________________ > 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 >
_______________________________________________ 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
