> On Feb 14, 2018, at 1:25 AM, Stijn Segers <f...@volatilesystems.org> wrote:
> Yousong Zhou <yszhou4t...@gmail.com> schreef op 14 februari 2018 09:06:11 CET:
>> No, it's just complicating things up. When people really cares about
>> the default settings' security, the will override the default by also
>> specifying files/etc/ssh/sshd_config besides
>> files/root/.ssh/authorized_keys. No need to pass on such complexity
>> as virtual packages and another config options for others.
> This only applies to OpenSSH, not Dropbear right? So this won't affect stock
> We should consider people rolling their own and using OpenSSH by default.
> This might be a nasty surprise - flash, reboot, realise you're locked out.
> SSH access from WAN is disabled by default anyway, as is access to the web
> interface. We already switched from telnet to SSH for initial login. I don't
> see any gaping security holes...
> On top of that, the project having a DIY spirit, if people start tinkering
> with SSH, they should know what they're doing. Just like when they start
> using LEDE/OpenWrt.
> My 2 cents
Yes, this would be for OpenSSH only… Dropbear has a UCI control that you can
change. (Yes, we could implement UCI for the 60 or so OpenSSH knobs, but it’s
sufficiently complicated that people might end up locking themselves out via
misconfiguration… so KISS)
Actually, SSH access from WAN is blocked by Firewall, but not “disabled by
default”. If your firewall settings get munged, then SSH is wide open (because
by default it listens to 0.0.0.0:22 which is unbound). Not exactly “defense in
Once I was messing with firewall settings and accidentally disabled the
firewall. Within a few minutes, there were all sorts of password attacks on
the WAN port. Having a sufficiently complex password slowed things down long
enough for me to re-secure the box.
Lede-dev mailing list