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

[Philip Prindeville]

> On Feb 14, 2018, at 3:00 PM, Magnus Kroken <mkroken at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20180215/a5ced54d/attachment.sig>