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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
