[LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Alberto Bursi]

On 14/02/2018 04:53, Philip Prindeville wrote:
>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>>
>> On 9 February 2018 at 08:28, Philip Prindeville
>> <philipp at redfish-solutions.com> wrote:
>>> From: Philip Prindeville <philipp at redfish-solutions.com>
>>>
>>> Allowing password logins leaves you vulnerable to dictionary
>>> attacks.  We disable password-based authentication, limiting
>>> authentication to keys only which are more secure.
>>>
>>> Note: You'll need to pre-populate your image with some initial
>>> keys. To do this:
>>>
>>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>>    from your top-level directory;
>>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>>    "files/root/.ssh/authorized_keys" and indeed, you can collect
>>>    keys from several sources this way by concatenating them;
>>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>>>
>> If forgetting doing this means I may need physical connection like vga
>> monitor or serial connection to "unlock" the device, very likely I
>> will hate this security enforcement...  It's just the inconvenience
>> regardless of whether the said situation should happen.  As a user I'd
>> like to keep this level of convenience as using password
>> authentication and turn it off when I see it appropriate.
>>
>>                 yousong
>>
>
> Well, we’re at an impasse because some people have said “this should be the new norm and it’s a mistake not to disable it unconditionally” and others have said the opposite, “yes, okay, let’s do this but only as an option”.
>
> So I’m happy to go other way but we should reach a consensus.
>
> What if it *is* an option but depends on a virtual package that takes a value (like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the /root/.ssh/authorized_keys file.
>
> Would that work for everyone?
>
> You could still lock yourself out of a box by (a) mis-formatting the keys or (b) getting the wrong public keys that don’t match your installed private keys, but getting this to be absolutely foolproof is a fool's errand.
>
> So what constitutes “good enough”?
>
> -Philip
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

That would be good for me only if the virtual package fails building and 
blocks the compilation if it does not find the file.

The part I'm worried about is just someone enabling a config option by 
mistake and getting locked out.

-Alberto