On Tue, 2019-04-16 at 14:11 -0700, Adam Williamson wrote:
> On Mon, 2019-04-15 at 20:42 -0600, Chris Murphy wrote:
> > On Mon, Apr 15, 2019 at 8:32 AM Martin Kolman <mkolman(a)redhat.com>
wrote:
> > > On Fri, 2019-04-12 at 13:33 -0600, Chris Murphy wrote:
> > > > Hi,
> > > >
> > > > I ran into this "fun" hack
> > > >
https://news.ycombinator.com/item?id=19642554 and I'm wondering
> > > > whether it'd be a good idea for F31 to ship with:
> > > >
> > > > #AllowAgentForwarding no
> > > > #PasswordAuthentication no
> > > >
> > > > Cockpit provides an interface to add SSH public keys for a while
now.
> > > > However the installer doesn't require creation of an admin user,
it's
> > > > an option.
> > >
> > > This is not entirely correct. During a "normal" installation
from network or
> > > DVD Anaconda, both interactive and kickstart Anaconda does require to have
one of:
> > > - a root user account with password set
> > > - a user in the wheel group
> > > If either of those is satisfied - or both - the installation can
proceed.
> >
> > I set a user without "Make this user administrator" checked, and
also
> > went to root user and locked it, did not set a password. And the
> > installer allow installation to proceed and quits without error.
> >
> > At the very least it would be nice if the installer made "Make this
> > user administrator" checked by default. But ideally I'd say check it,
> > and gray it out to indicate it's immutable. That user will be the
> > admin. It's inappropriate for root to be the admin.
>
> This would be a major policy change, it is not something to just
> randomly decide on a mailing list. (FWIW it would also break just about
> all the openQA tests, which all set a root password during
> installation, because that's much more straightforward than dealing
> with sudo.)
Especially for things like scp/rsync like for backups ... it's the
reason why I do not disable root, as I have my backup scripts that go
and fetch data from machines, and you can't really do that via sudo.
(would like to be illuminated if there is a way to do that with rsync
via sudo that does not involve giving fundamentally passwordless root
access to a "backup" user)
(Talking about disabling root logins here, of course I use ssh keys, not passwords)
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc