- 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