On 14/02/2018 04:53, Philip Prindeville wrote:
On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
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 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@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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
