[LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server
Philip Prindeville
philipp_subx at redfish-solutions.com
Wed Feb 14 11:23:26 PST 2018
> On Feb 14, 2018, at 1:06 AM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>
> On 14 February 2018 at 11:53, Philip Prindeville
> <philipp_subx at redfish-solutions.com> 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
>>
>
> No, it's just complicating things up. When people really cares about
> the default settings' security, the will override the default by also
> specifying files/etc/ssh/sshd_config besides
> files/root/.ssh/authorized_keys. No need to pass on such complexity
> as virtual packages and another config options for others.
>
> yousong
The problem with that is that if OpenSSH gets updated upstream, including changing the configuration file to address a CVE, I don’t want to keep installing a slightly mangled snapshot of a now-obsolete and vulnerable configuration.
That’s just exchanging one liability for another.
-Philip
More information about the Lede-dev
mailing list