Hello,
I'm writing a common reply for consolidation and brevity. I'll try to cover all
the concerns raised so far.
- Idea behind this feature is to keep malicious users from gaining 'root' access
to remote systems. Restricting remote root login increases the difficulty level in that,
which could thwart significant chunk of attacks. Guessing non-root user name is doable,
but still involves the complexity/work involved in doing that, which is _not same_ for all
malicious users. Few might be able to crack it, while others would _fail_ at it.
- 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. Either one would serve the purpose, but also
have implications on other workflows.
- Major concern so far is how this feature could break existing workflows. That is genuine
and can be addressed adequately. As said earlier in other threads, intention is certainly
_not_ to trouble users, but raise the security bar of Fedora systems a notch higher.
- 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. IMO, this feature certainly adds more value to Fedora than its perceived short
term cost.
Major use-cases discussed so far, across multiple threads are:
1. Local installations: wherein a user can navigate through the installation process as
prompted by the Anaconda installer. The system being installed could be local or remote.
The variant being installed could be server or workstation.
2. Automated installation: wherein a user can not navigate through the installation steps.
The variant could be sever or workstation.
3. Cloud installations: wherein cloud images are built via automation tools with
predefined configurations. Mostly these don't have(or need) non-root user account.
Towards a better solution:
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.
PermitRootLogin=without-password
* If we restrict remote 'root' access, exporting of ssh keys becomes imperative.
- Cloud_init tool seems to have facilities for that.
- Anaconda installer's state on this is not known yet.
- Such systems would still need non-root user access.
* Remote root access can be enabled in the '%post' install section of the
kick-start file.
-
https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html
Either approach entails some modifications to the current workflows. Though it seems
PermitRootLogin=no could do with lesser than 'without-password' option. As said in
the feature page,
"...There is another option of disabling root login via password and require usage
of cryptographic keys for the same. But that could be a next step in future."
Please see:
->
https://www.piratepad.ca/p/ssh-remoterootloigin
I have collated the above details on this pad. Please feel free to edit it as required.
Your comments/suggestions are most welcome. Once again, intention is _not_ to trouble
users, but to ensure their safety by default.
Thank you.
---Regards
-Prasad
http://feedmug.com