On 15.02.2018 16.52, Philip Prindeville wrote:
Well, right! That was my first approach with a “config" option to do exactly
that, but it was shot down:
https://github.com/openwrt/packages/pull/5520
I even defaulted the option to continue to allow passwords so that only people
who (a) selected OpenSSH and (b) turned this option off would be affected…
which has to be a small portion of the population.
Sorry, I must have missed this. I'm in favor of the current state of
that pull request (my concern is the direct consequences of the patch,
not the way it is implemented, more below).
Consider a scenario where a user builds an image with OpenSSH, without Dropbear
(because they have OpenSSH), and without a web interface (because they want to
save space). This is easily done by selecting and deselecting packages in
menuconfig/imagebuilder, no custom files needed today. With this change, if the
image is missing authorized_keys, the only way to log in is serial console
(failsafe will be locked out too), which requires soldering - or using
bootloader recovery features, which may also require soldering and aren't
consistently documented.
Actually, most of the boxes that *I* work on (Geos, Alix 2D, net5501, Xeon 1U
servers, etc.) all have serial ports and most of them have VGA as well (or
could if you install the optional header).
True, I was thinking of typical 5-port wireless routers. Still, the
lockout problem is real on those devices, and OpenWrt targets and
supports a lot of them.
This is just about the default configuration, it's not a choice between
conflicting compile time options with varying security implications. While key
authentication may be best practice, allowing SSH password logins isn't on the
level of reimplementing LuCI in PHP 4. The change is *literally* a handful of
sed commands, why can't advanced users take care of that themselves? Why do we
want to make it easier to build a soft-bricking image than it is today?
Conversely, why can’t advanced users have a clear, standardized way of doing
this? That they’re “advanced” doesn’t mean they don’t also appreciate
convenience, an easy way to save and export/import configurations, etc.
I'm not against general development, improvement or standardization of
config handling. I'm against the default state of the patch that started
this mail thread. The convenience of this patch opens up a new way to
break the convenience of failsafe on a lot of devices, and I don't think
many people would expect the particular package selection to cause such
a behavior. I consider failsafe to be more important. You've already
addressed that in your pull request, and I'm in favor of "this should be
configurable at build time, but the default behavior should not change".
How that is implemented is a different matter, which so far I haven't
thought much about.
In a perfect world, no one should ever have to build with patches, anything in
files/, cherry-picked commits, etc. Everything would be expressed in the
.config (or kernel-config).
I have a bunch of uci-defaults scripts (currently loaded via files) that
configure my devices after flashing (if any interface has MAC address X,
run a bunch of commands (uci stuff, sed, cat, service reloads,
whatever)). I keep adding to them without structuring things, and they
become unmanageable. One of many things I've thought of and never gotten
around to is creating a package feed of config script packages. A
package would e.g. be set_lan_ip4_addr, it would have configuration
option(s) to set the desired IP address in menuconfig, and then install
a generic uci-defaults script with the desired IP address inserted via
sed. Maybe there are better ways to do this (install a
/etc/config/deployment file that all the scripts read from?), anyway it
would be an improvement of what I do now. In theory, that could be used
to get any number of possibilities into menuconfig or .config as well.
-Philip
/Magnus
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
