F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Simo Sorce]

On Wed, 14 Jan 2015 05:53:23 +0000 (UTC)
P J P <pj.pandit at yahoo.co.in> wrote:

>   Hello Simo,
> 
> > On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote:
> > Sorry this is false. You got enough emails telling you this
> > change is undesirable, that's the definition of opposition
> > and means you have no _consensus_.
> 
> 
>   IIUC, that was for disabling remote root access completely with
> 'PermitRootLogin=no'. As the 'PermitRootLoing=without-password'
> option seems more preferred. As for the emails, many folks have also
> said that it is a useful change.

Ok, I state my opposition to without-password too inequivocably here.
Mostly because it is just the same as 'no', given there is no way, in a
regular install to seed a key into the root account.

> IMO, the ones opposing are those who fear their current
> setups/practices would break. Because they need remote 'root' access
> in their set-up. Which is a genuine use-case. And to support it, we
> could provide an option to enable remote root access with
> 'PermitRootLogin=Yes', based on the the user's response to Anaconda
> at install time, as was suggested in previous email. However, let's
> not assume _all_ Fedora users have this use-case.

Workstation do not even enable sshd (IIRC) so this impacts the server
images (cloud images already do their magic with sshd so I am not
counting them here), and server has different use cases and security
implications than a generic population.

> - IMHO, the change helps to harden Fedora systems and raise the
> security bar a notch higher. It is similar to how we run services as
> non-root user instead of 'root' user.

I disagree that there is any similarity, and it doesn't bring security
up a notch, most ssh attempts already probe for multiple users,
preventing just root+password login is just cosmetics if
user+password+sudo can do the same operations when broken in.

If you want to do something effective against password guessing attack
there are a few much better (and easy to implement) methods:

1) require a longer root password, so that brute forcing just fail
2) implement throttling so that trying to log in as root is
slowed down considerably (and the related brute-force)
3) implement temporary black-listing, so that an IP that fails a
pre-set number of times simply gets black-list for a pre-set period of
time.

> - The proposed change of using ssh keys for remote 'root' access
> introduces that mechanism to a wider audience, which in turn would
> help increase its usage in the future. Hence bring more value in the
> long term.

Except you have no mechanism to inject a key at installation time, you
would have to implement that first, *then* you can think of changing
the default.

> - IMO, it is beneficial to supply hardened default configurations,
> because they protect maximum users and have greater impact, than
> otherwise. Security is not a feature, it must be available by default.

Security and Usability are always at odds, exceeding in one and
destroying the other is always as bad. The solution you propose only
minimally affect security, the security increase is really negligible.
But the usability is affected greatly, I think disproportionally, which
is why I am opposed to this change.
I am not against hardening, but this is just make things diofficult for
little to no gain.

> - Of course that does not mean we overlook the usability aspect. As
> said before intention is _not_ to trouble users, but increase their
> safety as much as we can.

The intention may be not, then I'll call it poor execution/planning and
still oppose this move *at this time* unless there is proof we address
the usability problem first.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York