Yousong Zhou <> schreef op 14 februari 2018 09:06:11 CET:
>On 14 February 2018 at 11:53, Philip Prindeville
><> wrote:
>>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <>
>>> On 9 February 2018 at 08:28, Philip Prindeville
>>> <> wrote:
>>>> From: Philip Prindeville <>
>>>> 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/" (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
>>> 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
>>> 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

This only applies to OpenSSH, not Dropbear right? So this won't affect stock 

We should consider people rolling their own and using OpenSSH by default. This 
might be a nasty surprise - flash, reboot, realise you're locked out.

SSH access from WAN is disabled by default anyway, as is access to the web 
interface. We already switched from telnet to SSH for initial login. I don't 
see any gaping security holes... 

On top of that, the project having a DIY spirit, if people start tinkering with 
SSH, they should know what they're doing. Just like when they start using 

My 2 cents


>Lede-dev mailing list

Lede-dev mailing list

Reply via email to