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

[Miloslav Trmač]

> - The 'method' used to restrict remote root access is negotiable. Ie. disable
> it completely by setting PermitRootLogin=no  OR  disable remote root login
> via password by setting PermitRootLogin=without-password.

(The general theme of this mail: Being flexible is fine, and establishing this through this discussion is great; however, ultimately the Change proposal needs to document the _specific outcome_ of that discussion.²)


> - Major concern so far is how this feature could break existing workflows.
> That is genuine and can be addressed adequately.

“Can be” or “will be”?  How?  It is vaguely worrying that the Change proposal explicitly lists only the most trivial task to do (change a sshd.conf option) and is only fairly generic about how other parts of the OS and users need to and/or will adapt.


> PermitRootLogin=no
> * If we disable remote 'root' access, non-root user access becomes
> imperative.
>   - Anaconda & cloud_init tools already facilitate creation of non-root user
>   accounts.
>   - Creation of one non-root account could be made mandatory.
>   - Omission of non-root account creation could show discretionary warning.
>   - Omission of such user account creation could conditionally enable remote
>   root access.

“Could conditionally“…  With my FESCo hat on, during the Change Checkpoints FESCo will need to know whether the Change is sufficiently complete or whether to fall back to the contingency plan.  Having a “Could conditionally” nailed down to yes or no would prevent general unhappiness if the respective package maintainers thought that they have done the right thing and FESCo during review suddenly decided that the right thing is the opposite.


Separately from the general theme above,
> - Second tune is that the feature does not add any security. That is like
> saying having a security guard at the entrance adds no value, because
> atrocities still continue to happen around us.

The requirement to know a user name, which is in most cases just an automatable task¹ nobody is trying to prevent or make harder, is not really the same as a requirement to bypass a security mechanism (subdue a guard or guess a password).  It’s been about 10 years already since I have witnessed an automated password guessing bot carrying a list of user names and real names from previously infected systems as a “crib sheet” for guessing on new systems; this is not a hypothetical thing that bot authors are too dumb or lazy to do.  So this proposal only helps if we hope that a bot won’t try the right user name; calling this security by obscurity is not too wide off the mark.
    Mirek