> On Feb 14, 2018, at 3:00 PM, Magnus Kroken <mkro...@gmail.com> wrote: > > On 14.02.2018 22.13, Michelle Sullivan wrote: >> FWIW, I had misunderstood the intent of the original comments... OpenSSH >> server vs Dropbear - if someone is using OpenSSH server they already >> went in with advanced config as Dropbear is the default - I'd err on the >> side of security as they should already know what they are doing.... it >> should be recoverable by webinterface though (rather than worrying about >> people 'fixing' by using something not secure.) > > The opposite argument applies equally well IMO: they already know what they > are doing, they should know how to allow key authentication only if they want > that.
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. > > 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). > > 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. -Philip > > Regards > /Magnus
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
