Yousong Zhou <yszhou4t...@gmail.com> schreef op 14 februari 2018 09:06:11 CET:
>On 14 February 2018 at 11:53, Philip Prindeville
>>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com>
>>> On 9 February 2018 at 08:28, Philip Prindeville
>>> <phil...@redfish-solutions.com> wrote:
>>>> From: Philip Prindeville <phil...@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
>>> 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.
>> 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
>> 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”?
>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.
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