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

[Daniel Golle]

Hi!

On Thu, Feb 15, 2018 at 08:51:23AM -0700, Philip Prindeville wrote:
> > 
> > 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.
> 
> 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).
> 
> And again, not every box would be bricked.  Like I said, all of mine have serial consoles and most of them have VGA.
> 
> 
> > 
> > How about adding a configuration flag to menuconfig for OpenSSH, which runs said sed commands if the flag is set (disabled by default, for the reasons above). It makes it easier to set for those who want it, and it will also be saved in a diffconfig output if they set that.
> 
> 
> Did exactly that in the original PR but it was vetoed.

Watching this going back and forth I must admit that there is no good
way of handling config-overlay provisioning of images. (or is there?)

The informal idea of the workflow goes like

buildroot -> imagebuilder -> run-time

while in each phase only the truely neccessary choices are made and
provisioning of the image happening using the imagebuilder FILES=
parameter (ie. when rootfs is created, after packages are installed).

Obviously this approach does have flaws, to illustrate that, lets look
at the options you got in order to achieve your goal in that model:
 - keep a synced copy of the file and pass it to imagebuilder using
   FILES=...
 - have an additional package which sed-patches the config file in
   post-install *and* run-time in case of the openssh package being
   updated via opkg
 - have a local VARIANT=nopwdauth of the openssh package which
   PROVIDES=... the former and has a deviating default config shipped.

All three don't look particularly 'clean' to me...
Even if you had abstracted all or at least the part of the opensshd
configuration necessary for you in UCI, there would be no particularly
more clean option to divert from the defaults -- you'd end up with
/etc/config/opensshd.opkg-new every time you update openssh via opkg
unless you implement a way to migrate updated config options (which
is what we do for some very fundamental packages because users may
decide to keep the configuration when using sysupgrade, so also there
config-migration has to be taken care of, but for opkg we just don't
care)

My feeling is still that 'keeping it flat' by simply overloading that
one file using the FILES= statement of either imagebuilder or buildroot
and having that local config kept in-sync is still the best option you
got -- for now the increased complexity and maintainance of any of the
infrastructural changes which came up to better model such use-cases
don't seem to really be worth it (in terms of actually solving the
problem).

The deep problem we are looking it imho is the fact that UCI in its
current form is insufficient. It doesn't model the difference of
generic configuration (think: dhcp) which is applied for any service
implementing that functionality (think: dnsmasq, odhcpd, isc-dhcp)
and implementation-specific configuration (think: the odhcpd section
inside the dhcp config vs. dropbear having its indidivual config).
It also doesn't model on which layer a configuration change was
made (distribution/build-time, uci-defaults/firstboot, provisioning,
management or user) neither the scope of the change (global,
target-platform, device-type-specific, organisational structures or
individual boxes).
Not even mentioning the disadvantages of UCI's 'dynamic typing' when
on the other hand, ubus and json got defined basic types.
And the debate about anonymous config sections still causes pts for
many of us...

These and many other reasons made people talk about replacing UCI with
something more modern for almost a decade -- it's simplicity and
popularity with users, however, made UCI survive up to now.

Maybe we should have a configuration/modelling/management/provisioning
track at the upcoming OpenWrt Summit...?


Cheers


Daniel