sshd defaults in server

[Chris Murphy]

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?

[Jakub Jelen]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Simo Sorce]

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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
>
> -- 
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
> _______________________________________________
> server mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Chris Murphy]

On Mon, Apr 15, 2019 at 6:20 AM 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.

Oh man... I just now realized that this is not the default. I somehow
forgot I set this to no on all my machines. And I just did a Fedora 30
Server install and "yes" is the default.

Do I understand this correctly, that Fedora is setting this contrary
to upstream for 4 years now?
https://github.com/openssh/openssh-portable/commit/88a7c598a94ff53f76df228ee...

[Martin Kolman]

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.

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 ?

It is only in the special case od the live installation that we allow the installation
to proceed without the above condition (root with password/user in wheel group),
due to the root and user configuration spokes being disabled.
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Martin Kolman]

On Mon, 2019-04-15 at 16:31 +0200, Martin Kolman 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.
>
> 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 ?
>
> It is only in the special case od the live installation that we allow the installation
> to proceed without the above condition (root with password/user in wheel group),
> due to the root and user configuration spokes being disabled.

A slight correct, I mean the Fedora Workstation live. The other Fedora live spins AFAIK
have the root & user configuration screens.
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
>
> server mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Chris Murphy]

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

[Adam Williamson]

On Mon, 2019-04-15 at 20:42 -0600, Chris Murphy wrote:
> On Mon, Apr 15, 2019 at 8:32 AM Martin Kolman  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.)

[Simo Sorce]

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  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.

[Simo Sorce]

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

[Jakub Jelen]

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 <
> > > > [e-mail]> 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,

[Stephen John Smoogen]

On Thu, 18 Apr 2019 at 04:50, Jakub Jelen  wrote:
> 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 <
> > (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.

You can send Fedora 31 and Fedora 32 change proposals to Ben Cotten already.
> Regards,
>
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
> _______________________________________________
> server mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Adam Williamson]

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.