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”?
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/
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
