People that build there own images and choose OpenSSH would be expected to know what they are doing and for that reason not allowing password logins as a default seems reasonable, but ... even those knowledgeable users may sometimes forget to add a public key and find their lovely router soft bricked.
Users that choose OpenSSH, may indeed want to disable passwords. They can do so safely *once* they've set-up their public keys, either at image build-time or at run-time, even when the default allows passwords. In general avoiding locking out users by allowing passwords as a (first) default seems reasonable as it does not interfere with securing a box. (this adheres to John Stuart Mill's harm principle) To many words, bye, Paul > Op 15 feb. 2018, om 20:50 heeft Magnus Kroken <mkro...@gmail.com> het > volgende geschreven: > > 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 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
