Yousong Zhou <yszhou4t...@gmail.com> schreef op 14 februari 2018 09:06:11 CET: >On 14 February 2018 at 11:53, Philip Prindeville ><philipp_s...@redfish-solutions.com> wrote: >> >>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com> >wrote: >>> >>> On 9 February 2018 at 08:28, Philip Prindeville >>> <phil...@redfish-solutions.com> wrote: >>>> From: Philip Prindeville <phil...@redfish-solutions.com> >>>> >>>> Allowing password logins leaves you vulnerable to dictionary >>>> attacks. We disable password-based authentication, limiting >>>> authentication to keys only which are more secure. >>>> >>>> Note: You'll need to pre-populate your image with some initial >>>> keys. To do this: >>>> >>>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh" >>>> from your top-level directory; >>>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into >>>> "files/root/.ssh/authorized_keys" and indeed, you can collect >>>> keys from several sources this way by concatenating them; >>>> 3. Set the permissions on "authorized_keys" to 644 or 640. >>>> >>> >>> If forgetting doing this means I may need physical connection like >vga >>> monitor or serial connection to "unlock" the device, very likely I >>> will hate this security enforcement... It's just the inconvenience >>> regardless of whether the said situation should happen. As a user >I'd >>> like to keep this level of convenience as using password >>> authentication and turn it off when I see it appropriate. >>> >>> yousong >>> >> >> >> Well, we’re at an impasse because some people have said “this should >be the new norm and it’s a mistake not to disable it unconditionally” >and others have said the opposite, “yes, okay, let’s do this but only >as an option”. >> >> So I’m happy to go other way but we should reach a consensus. >> >> What if it *is* an option but depends on a virtual package that takes >a value (like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the >/root/.ssh/authorized_keys file. >> >> Would that work for everyone? >> >> You could still lock yourself out of a box by (a) mis-formatting the >keys or (b) getting the wrong public keys that don’t match your >installed private keys, but getting this to be absolutely foolproof is >a fool's errand. >> >> So what constitutes “good enough”? >> >> -Philip >> > >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. > > yousong >
This only applies to OpenSSH, not Dropbear right? So this won't affect stock images? 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 Stijn >_______________________________________________ >Lede-dev mailing list >Lede-dev@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/lede-dev _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
