[LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Magnus Kroken]

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