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

[Paul Oranje]

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 <mkroken at 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 at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel