Isn't the issue always the same? Namely network installs that need ability to log in as root+password until further setup can be done? It'd be nice if there were a way to automatically determine that another form of login is possible, and disable password only if that's certain ...

Simo.

On Mon, 2019-04-15 at 14:20 +0200, Jakub Jelen wrote:

Hello, I see more viable to resurrect a bug #89216 [1] and change a default configuration (not only in fedora server) to

PermitRootLogin no

or at least prohibit-password. It can at least nudge for using better workflows using sudo.

I did not have an energy to persuade this change during last years, especially because there used to be such a huge pushback in the past.

If you wish to help me in this way, I would strongly appreciate this change in OpenSSH.

SSH agent forwarding can be indeed dangerous, but only if the server was already compromised (by running outdated system with privilege escalation vulnerabilities).

Regards, Jakub

[1] https://bugzilla.redhat.com/show_bug.cgi?id=89216

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.

Related to that, I'd like to see the installer: a. Require creation of a non-root user with "Make this user administrator" checked by default b. Root user has "Lock root account" checked by default

When I check "lock root account" and return to the installation overview, it shows for root user that logins are disabled, so it's not like the person doing the install has to go dig around for the fact root user will be disabled. And they can easily uncheck it and set a password.

Any thoughts?

-- Chris Murphy _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-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/server@lists.fedoraproject.org

-- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-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/server@lists.fedoraproject.org

On Mon, Apr 15, 2019 at 8:32 AM Martin Kolman mkolman@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.

-- Chris Murphy

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@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)

Simo.

On Wed, 2019-04-17 at 12:40 -0400, Simo Sorce wrote:

On Wed, 2019-04-17 at 12:39 -0400, Simo Sorce wrote:

...

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@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)

The proposal to follow upstream would be disabling only the root password logins so your scripts will be intact.

To actually see what and who is going to be broken by this we will probably have to do the change itself so we should really start with the change proposal as soon as the Fedora 30 will be out.

Regards,

On Mon, 2019-04-15 at 16:31 +0200, Martin Kolman wrote:

Note that this does not check for the root/user account being locked. Apparently Anaconda is just fine with a system that only has a root account with password set, which is locked. I guess this could still be considered fine for some use cases ?

There are various cases...cloud images and ARM disk images come this way out of the box, I believe. Cloud platforms have their own mechanisms for setting up initial auth to the system, ARM disk images boot straight into initial-setup and require setting of a new root password or creation of an admin user at that point...

and of course for the last few releases, Workstation installs work much like ARM disk images, user creation / root PW set is disabled during initial install and you are forced through g-i-s to create an admin user at first boot.