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

[Michelle Sullivan]

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”?
>

Personally - my thoughts ....

There should be an option to enable passwords (default off...)
A warning should be placed on the checkbox to inform the user it is not 
a good idea to enable them.
SSH should be disabled on external interfaces unless specifically 
enabled. (what constitutes 'external' if there is no 'wan' port? ...i.e. 
AP only?)
SSH without password in place and no keys should be unconditionally 
disabled (and not enable-able - except by hand editing.)
One could try to do what some manufacturers have done and open ssh for a 
period of time if the WPS button is depressed for a certain length of 
time  as a 'fool proof' command login.... personally though I think 
anyone using SSH instead of the webinterface is more than likely going 
to know what they are doing and therefore it should not be an issue... 
ie err on the side of 'there is an idiot at the controls, lets make it 
default as secure as possible'...

-- 
Michelle Sullivan
http://www.mhix.org/