About sshd(8) PermitRootLogin=no

Reindl Harald h.reindl at thelounge.net
Wed Dec 17 16:23:35 UTC 2014


Am 17.12.2014 um 17:05 schrieb P J P:
>> On Tuesday, 16 December 2014 10:57 PM, Simo Sorce wrote:
>> The thing need to be done during install, my servers boot unattended.
>
>> No the key-word here is "easily", which is misguided.
>> It is not *easy* to have to jump through hoops to get a KVM/spice
>> connection to log in through the console to then go and change an
>> option.
>>
>> It is not easy and it is not automatable, so you break a ton of
>> deployment/qa/automation scripts people rely on.
>
> Sure, I agree. I'm not sure how these VM images are created and deployed,
> but there must be some way to handle such cases,
>
> ex -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204663.html
>
> As said before, intention is not to break things too rough and bother users.
> But to make things secure while keeping them usable. If they are not usable,
> what good is that security?

Anaconda should just ask for sshd yes/no with defaults to no and in that 
case not enable the service at all

* forcing me to create a non-root user is a nogo
   there are machines where you never connect except for admin tasks

* "PermitRootLogin no" is idiotic  in any case because the safe setting
   "PermitRootLogin without-password" exists and enforces a private key
   while there is no public key without generate and install it

* well, and you need a first time root login with password to
   import such a key and then disable password login

hence just don't enable the service on each and every machine and ask 
the user if he needs a ssh server at install time - i know, in times 
where it's not popular to ask a user for anything not likely to happen

what will not work is magically guess the users intention and provide 
secure defaults at the same time, not now and not in the future

*ask users* and default to *no* because if someone say "yes" by 
intention it's his own responsibility to secure it

and *do not* touch existing configurations, never, in no context

i have seen networks going down because stupid named-maintainers decided 
to mangle "named.conf" by add dnssec options unasked with regular yum 
updates

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20141217/cdbb1b2b/attachment.sig>


More information about the security mailing list