hey All,

On 2/15/2018 20:50, Magnus Kroken 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.
> 
> 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.

i am following this PR since the start and hold the same reservations. how 
about a menuconfig option that allows you to activate this feature and allows 
to define a path to an 'authorized_keys' file.
implemented for all sshd packages this would squash all requirements into one 
solution, or not?

..ede
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to