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

2018-02-17 Thread Rosen Penev 
On Sat, Feb 17, 2018 at 1:54 PM, Stijn Tintel  wrote:
> On 09-02-18 01:28, Philip Prindeville wrote:
>> From: Philip Prindeville 
>>
>> 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.
>>
>>
> NAK. This is going to bite people. It takes much more time and effort to
> recover from a device you can no longer access due to this change, than
> to manually disable password authentication in OpenSSH.
On that note, how do you recover with OpenSSH? Currently, root
password access is disabled. My method is to install dropbear and use
that temporarily while i enable root password access.
>
>
> ___
> 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

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

2018-02-17 Thread Stijn Tintel 
On 09-02-18 01:28, Philip Prindeville wrote:
> From: Philip Prindeville 
>
> 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.
>
>
NAK. This is going to bite people. It takes much more time and effort to
recover from a device you can no longer access due to this change, than
to manually disable password authentication in OpenSSH.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-17 Thread Karl Palsson 

Philip Prindeville  wrote:
> 
> 
> 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).

I think this is probably the root of all the discussion. I agree
with you that most people shouldn't want patches, but I think
it's rather silly to say that it should all be via .config.
Putting things in files/ is vastly easier and more flexible than
trying to create something for everyone in makefile and kconfig
syntax!

I'd generally rather see a lot _less_ of things created via an
ever expanding .config and _more_ local customizations applied as
local customizations :)

Cheers,
Karl Palsson



signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-15 Thread Magnus Kroken 

On 15.02.2018 16.52, Philip Prindeville wrote:

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.


Sorry, I must have missed this. I'm in favor of the current state of 
that pull request (my concern is the direct consequences of the patch, 
not the way it is implemented, more below).



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).


True, I was thinking of typical 5-port wireless routers. Still, the 
lockout problem is real on those devices, and OpenWrt targets and 
supports a lot of them.



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.



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).


I have a bunch of uci-defaults scripts (currently loaded via files) that 
configure my devices after flashing (if any interface has MAC address X, 
run a bunch of commands (uci stuff, sed, cat, service reloads, 
whatever)). I keep adding to them without structuring things, and they 
become unmanageable. One of many things I've thought of and never gotten 
around to is creating a package feed of config script packages. A 
package would e.g. be set_lan_ip4_addr, it would have configuration 
option(s) to set the desired IP address in menuconfig, and then install 
a generic uci-defaults script with the desired IP address inserted via 
sed. Maybe there are better ways to do this (install a 
/etc/config/deployment file that all the scripts read from?), anyway it 
would be an improvement of what I do now. In theory, that could be used 
to get any number of possibilities into menuconfig or .config as well.



-Philip


/Magnus

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-15 Thread Daniel Golle 
Hi!

On Thu, Feb 15, 2018 at 08:51:23AM -0700, Philip Prindeville 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.
> 
> 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.

Watching this going back and forth I must admit that there is no good
way of handling config-overlay provisioning of images. (or is there?)

The informal idea of the workflow goes like

buildroot -> imagebuilder -> run-time

while in each phase only the truely neccessary choices are made and
provisioning of the image happening using the imagebuilder FILES=
parameter (ie. when rootfs is created, after packages are installed).

Obviously this approach does have flaws, to illustrate that, lets look
at the options you got in order to achieve your goal in that model:
 - keep a synced copy of the file and pass it to imagebuilder using
   FILES=...
 - have an additional package which sed-patches the config file in
   post-install *and* run-time in case of the openssh package being
   updated via opkg
 - have a local VARIANT=nopwdauth of the openssh package which
   PROVIDES=... the former and has a deviating default config shipped.

All three don't look particularly 'clean' to me...
Even if you had abstracted all or at least the part of the opensshd
configuration necessary for you in UCI, there would be no particularly
more clean option to divert from the defaults -- you'd end up with
/etc/config/opensshd.opkg-new every time you update openssh via opkg
unless you implement a way to migrate updated config options (which
is what we do for some very fundamental packages because users may
decide to keep the configuration when using sysupgrade, so also there
config-migration has to be taken care of, but for opkg we just don't
care)

My feeling is still that 'keeping it flat' by simply overloading that
one file using the FILES= statement of either imagebuilder or buildroot
and having that local config kept in-sync is still the best option you
got -- for now the increased complexity and maintainance of any of the
infrastructural changes which came up to better model such use-cases
don't seem to really be worth it (in terms of actually solving the
problem).

The deep problem we are looking it imho is the fact that UCI in its
current form is insufficient. It doesn't model the difference of
generic configuration (think: dhcp) which is applied for any service
implementing that functionality (think: dnsmasq, odhcpd, isc-dhcp)
and implementation-specific configuration (think: the odhcpd section
inside the dhcp config vs. dropbear having its indidivual config).
It also doesn't model on which layer a configuration change was
made (distribution/build-time, uci-defaults/firstboot, provisioning,
management or user) neither the scope of the change (global,
target-platform, device-type-specific, organisational structures or
individual boxes).
Not even mentioning the disadvantages of UCI's 'dynamic typing' when
on the other hand, ubus and json got defined basic types.
And the debate about anonymous config sections still causes pts for
many of us...

These and many other reasons made people talk about replacing UCI with
something more modern for almost a decade -- it's simplicity and
popularity with users, however, made UCI survive up to now.

Maybe we should have a configuration/modelling/management/provisioning
track at the upcoming OpenWrt Summit...?


Cheers


Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-15 Thread Philip Prindeville 

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


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-15 Thread Philip Prindeville 


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

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

2018-02-14 Thread Alberto Bursi 



On 02/14/2018 10:53 PM, David Woodhouse wrote:

On Wed, 2018-02-14 at 22:51 +0100, Alberto Bursi wrote:

Just change the WAN ssh port number to something in the dynamic port
range, pretty much 0 bots scan beyond the few well-known ports
range, and you save CPU resources too.

We're talking about the default config here though. Please let's not
encourage bogus security-through-obscurity measures in that context.


Your firewall rules weren't about security either but about twarting 
dumb bots doing internet-wide scans.
And for that I think there are better ways that also save CPU resources, 
as I said.


The security here still comes from having ssh using a key instead of a 
password, or at the very least a very good password. (although I still 
think the key is much better)


I quite frankly don't see why the default config should even enable ssh 
on WAN at all (apart from special cases on some devices that only have 
one port maybe), if the user wants to he should set it up on his own.


-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Magnus Kroken 

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.


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.


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?


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.


Regards
/Magnus

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Michelle Sullivan 

David Woodhouse wrote:

On Wed, 2018-02-14 at 22:51 +0100, Alberto Bursi wrote:

Just change the WAN ssh port number to something in the dynamic port
range, pretty much 0 bots scan beyond the few well-known ports
range, and you save CPU resources too.

We're talking about the default config here though. Please let's not
encourage bogus security-through-obscurity measures in that context.


+1

--
Michelle Sullivan
http://www.mhix.org/


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread David Woodhouse 
On Wed, 2018-02-14 at 22:51 +0100, Alberto Bursi wrote:
> Just change the WAN ssh port number to something in the dynamic port 
> range, pretty much 0 bots scan beyond the few well-known ports
> range, and you save CPU resources too.

We're talking about the default config here though. Please let's not
encourage bogus security-through-obscurity measures in that context.

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Alberto Bursi 



On 02/14/2018 10:36 PM, David Woodhouse wrote:

On Wed, 2018-02-14 at 12:34 -0700, Philip Prindeville wrote:

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.

Pfft. If you had a half-decent password, the box was always secure.

If you really care, perhaps roll something like this (which I have in
my /etc/firewall.user) into the default configuration:

for PROTO in iptables ip6tables ; do
    for TABLE in forwarding_rule input_rule; do
   $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --rcheck --hitcount 
4 --seconds 60 -j LOG --log-prefix "SSH_BRUTE "
   $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --update 
--hitcount 4 --seconds 60 -j REJECT --reject-with tcp-reset
   $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --set -j 
RETURN
    done
done

You have the same "problem" with external access via HTTPS, surely? Are
you planning to ban password access to that too?



Just change the WAN ssh port number to something in the dynamic port 
range, pretty much 0 bots scan beyond the few well-known ports range, 
and you save CPU resources too.


-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread David Woodhouse 
On Wed, 2018-02-14 at 12:34 -0700, Philip Prindeville wrote:
> 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.

Pfft. If you had a half-decent password, the box was always secure.

If you really care, perhaps roll something like this (which I have in
my /etc/firewall.user) into the default configuration:

for PROTO in iptables ip6tables ; do
   for TABLE in forwarding_rule input_rule; do
  $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --rcheck 
--hitcount 4 --seconds 60 -j LOG --log-prefix "SSH_BRUTE "
  $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --update 
--hitcount 4 --seconds 60 -j REJECT --reject-with tcp-reset
  $PROTO -A $TABLE -p tcp --dport 22 --syn -m recent --name SSH --set -j 
RETURN
   done
done

You have the same "problem" with external access via HTTPS, surely? Are
you planning to ban password access to that too?

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Michelle Sullivan 

Philip Prindeville wrote:



On Feb 13, 2018, at 9:14 PM, Michelle Sullivan  wrote:

[snip]
Personally - my thoughts 

There should be an option to enable passwords (default off...)
A warning should be placed on the checkbox to inform the user it is not a good 
idea to enable them.
SSH should be disabled on external interfaces unless specifically enabled. 
(what constitutes 'external' if there is no 'wan' port? ...i.e. AP only?)
SSH without password in place and no keys should be unconditionally disabled 
(and not enable-able - except by hand editing.)
One could try to do what some manufacturers have done and open ssh for a period 
of time if the WPS button is depressed for a certain length of time  as a 'fool 
proof' command login personally though I think anyone using SSH instead of 
the webinterface is more than likely going to know what they are doing and 
therefore it should not be an issue... ie err on the side of 'there is an idiot 
at the controls, lets make it default as secure as possible'...

--
Michelle Sullivan
http://www.mhix.org/



Thanks for the suggestion.  Alas OpenSSH allows one to specify a ListenAddress 
which you could match to the “lan” or “wan” address(es).  Problem is that if 
you’re using DHCP on the “wan”, you’d have to rewrite the file (and restart the 
service) every time DHCP changed the address on the interface.

What would be better is if OpenSSH had a ListenInterface configuration 
parameter instead, and used netlink to listen for address changes… but that 
would be a bit of complexity (although you’d think it would be a common enough 
requirement for applications that someone would have come up with a library to 
do exactly that in a portable fashion).

Your conclusion is spot on: it’s hard to offer good security and make it 
foolproof at the same time because the approaches go in exactly opposite 
directions.  Security requires extreme pessimism, even paranoia, and 
user-friendliness implies being extremely forgiving.

It’s hard to have both.

-Philip

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.)


--
Michelle Sullivan
http://www.mhix.org/


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Philip Prindeville 


> On Feb 14, 2018, at 1:25 AM, Stijn Segers  wrote:
> 
> Yousong Zhou  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.
>> 
>>   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
> 


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 
depth”.

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.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Philip Prindeville 


> On Feb 14, 2018, at 1:06 AM, Yousong Zhou  wrote:
> 
> On 14 February 2018 at 11:53, Philip Prindeville
>  wrote:
>> 
>>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:
>>> 
>>> On 9 February 2018 at 08:28, Philip Prindeville
>>>  wrote:
 From: Philip Prindeville 
 
 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


The problem with that is that if OpenSSH gets updated upstream, including 
changing the configuration file to address a CVE, I don’t want to keep 
installing a slightly mangled snapshot of a now-obsolete and vulnerable 
configuration.

That’s just exchanging one liability for another.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Philip Prindeville 


> On Feb 13, 2018, at 9:14 PM, Michelle Sullivan  wrote:
> 
> [snip]
> Personally - my thoughts 
> 
> There should be an option to enable passwords (default off...)
> A warning should be placed on the checkbox to inform the user it is not a 
> good idea to enable them.
> SSH should be disabled on external interfaces unless specifically enabled. 
> (what constitutes 'external' if there is no 'wan' port? ...i.e. AP only?)
> SSH without password in place and no keys should be unconditionally disabled 
> (and not enable-able - except by hand editing.)
> One could try to do what some manufacturers have done and open ssh for a 
> period of time if the WPS button is depressed for a certain length of time  
> as a 'fool proof' command login personally though I think anyone using 
> SSH instead of the webinterface is more than likely going to know what they 
> are doing and therefore it should not be an issue... ie err on the side of 
> 'there is an idiot at the controls, lets make it default as secure as 
> possible'...
> 
> -- 
> Michelle Sullivan
> http://www.mhix.org/
> 


Thanks for the suggestion.  Alas OpenSSH allows one to specify a ListenAddress 
which you could match to the “lan” or “wan” address(es).  Problem is that if 
you’re using DHCP on the “wan”, you’d have to rewrite the file (and restart the 
service) every time DHCP changed the address on the interface.

What would be better is if OpenSSH had a ListenInterface configuration 
parameter instead, and used netlink to listen for address changes… but that 
would be a bit of complexity (although you’d think it would be a common enough 
requirement for applications that someone would have come up with a library to 
do exactly that in a portable fashion).

Your conclusion is spot on: it’s hard to offer good security and make it 
foolproof at the same time because the approaches go in exactly opposite 
directions.  Security requires extreme pessimism, even paranoia, and 
user-friendliness implies being extremely forgiving.

It’s hard to have both.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-14 Thread Stijn Segers 
Yousong Zhou  schreef op 14 februari 2018 09:06:11 CET:
>On 14 February 2018 at 11:53, Philip Prindeville
> wrote:
>>
>>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou 
>wrote:
>>>
>>> On 9 February 2018 at 08:28, Philip Prindeville
>>>  wrote:
 From: Philip Prindeville 

 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

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

2018-02-13 Thread Alberto Bursi 



On 14/02/2018 04:53, Philip Prindeville wrote:

On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:

On 9 February 2018 at 08:28, Philip Prindeville
 wrote:

From: Philip Prindeville 

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


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


That would be good for me only if the virtual package fails building and 
blocks the compilation if it does not find the file.


The part I'm worried about is just someone enabling a config option by 
mistake and getting locked out.


-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-13 Thread Michelle Sullivan 

Philip Prindeville wrote:

On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:

On 9 February 2018 at 08:28, Philip Prindeville
 wrote:

From: Philip Prindeville 

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”?



Personally - my thoughts 

There should be an option to enable passwords (default off...)
A warning should be placed on the checkbox to inform the user it is not 
a good idea to enable them.
SSH should be disabled on external interfaces unless specifically 
enabled. (what constitutes 'external' if there is no 'wan' port? ...i.e. 
AP only?)
SSH without password in place and no keys should be unconditionally 
disabled (and not enable-able - except by hand editing.)
One could try to do what some manufacturers have done and open ssh for a 
period of time if the WPS button is depressed for a certain length of 
time  as a 'fool proof' command login personally though I think 
anyone using SSH instead of the webinterface is more than likely going 
to know what they are doing and therefore it should not be an issue... 
ie err on the side of 'there is an idiot at the controls, lets make it 
default as secure as possible'...


--
Michelle Sullivan
http://www.mhix.org/


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-13 Thread Philip Prindeville 

> On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:
> 
> On 9 February 2018 at 08:28, Philip Prindeville
>  wrote:
>> From: Philip Prindeville 
>> 
>> 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


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-11 Thread Philip Prindeville 


> On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:
> 
> On 9 February 2018 at 08:28, Philip Prindeville
>  wrote:
>> From: Philip Prindeville 
>> 
>> 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

I originally did it as a Config setting which modified the config file at 
build-time (PR #5520) but this was vetoed.

Personally I thought allowing everyone to crank down the system as much as they 
saw appropriate was the best solution.

-Philip

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-11 Thread Philip Prindeville 


> On Feb 11, 2018, at 3:54 AM, Yousong Zhou  wrote:
> 
> On 9 February 2018 at 08:28, Philip Prindeville
>  wrote:
>> From: Philip Prindeville 
>> 
>> 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


I originally did it as a Config setting which modified the config file at 
build-time (PR #5520) but this was vetoed.

Personally I thought allowing everyone to crank down the system as much as they 
saw appropriate was the best solution.

-Philip
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-11 Thread Philip Prindeville 




Sent from my iPhone
> On Feb 11, 2018, at 4:11 AM, Torbjorn Jansson 
>  wrote:
> 
>> On 2018-02-11 11:54, Yousong Zhou wrote:
>> On 9 February 2018 at 08:28, Philip Prindeville
>>  wrote:
>>> From: Philip Prindeville 
>>> 
>>> 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
> 
> yes and i assume this will be a feature that is off by default, especially in 
> images created as part of making a new release.
> 
> if it is on by default in images available for download on lede/openwrt site 
> then we have a big problem.


By default images are built using dropbear not openssh.




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-11 Thread Alberto Bursi 



On 02/11/2018 11:54 AM, Yousong Zhou wrote:

On 9 February 2018 at 08:28, Philip Prindeville
 wrote:

From: Philip Prindeville 

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




This is the risk I also pointed out myself in the github PR about this.

Either this patch adds logic to check if there is indeed the right files 
in /files

and aborts building if not found or you risks locking out yourself.

-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-11 Thread Torbjorn Jansson 

On 2018-02-11 11:54, Yousong Zhou wrote:

On 9 February 2018 at 08:28, Philip Prindeville
 wrote:

From: Philip Prindeville 

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


yes and i assume this will be a feature that is off by default, especially in 
images created as part of making a new release.


if it is on by default in images available for download on lede/openwrt site 
then we have a big problem.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-11 Thread Yousong Zhou 
On 9 February 2018 at 08:28, Philip Prindeville
 wrote:
> From: Philip Prindeville 
>
> 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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-10 Thread Michelle Sullivan 

Paul Oranje wrote:

Your aptness for seeing the possible attack vectors warrants your judgement ...


Op 10 feb. 2018, om 17:07 heeft Philip Prindeville 
 het volgende geschreven:



On Feb 10, 2018, at 3:28 AM, Paul Oranje  wrote:

Wouldn't it be appropriate to disallow password authentication on wan only and allow it 
on all networks "behind" the router?

Not necessarily.

That’s why UPnP is such an issue. A machine inside a firewall gets infected by 
a virus through a download or email... then the first thing the virus does is 
punch holes in the firewall to allow outside scans of the remaining hosts.

Allowing password logins from an infected host just means that the virus has to 
do slightly more work before it owns the router (ie run a password attack).

Not substantially more secure...



uPNP should be disabled by default and where possible as it is a 
security hazard for those that understand it.  For those that don't it's 
a compromise waiting to happen.


Juniper doesn't support uPNP in the commercial market at all (and even 
given their statement in 
https://kb.juniper.net/InfoCenter/index?page=content=KB5615 I can 
point out that even in their semi-residential products - ie their small 
office gear doesn't support it either I'd suggest that any support for 
uPNP is off by default and gives a warning if someone tries to enable it.)


--
Michelle Sullivan
http://www.mhix.org/


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-10 Thread Michelle Sullivan 

Philip Prindeville wrote:



On Feb 10, 2018, at 6:03 PM, Michelle Sullivan  wrote:

Paul Oranje wrote:

Your aptness for seeing the possible attack vectors warrants your judgement ...


Op 10 feb. 2018, om 17:07 heeft Philip Prindeville 
 het volgende geschreven:



On Feb 10, 2018, at 3:28 AM, Paul Oranje  wrote:

Wouldn't it be appropriate to disallow password authentication on wan only and allow it 
on all networks "behind" the router?

Not necessarily.

That’s why UPnP is such an issue. A machine inside a firewall gets infected by 
a virus through a download or email... then the first thing the virus does is 
punch holes in the firewall to allow outside scans of the remaining hosts.

Allowing password logins from an infected host just means that the virus has to 
do slightly more work before it owns the router (ie run a password attack).

Not substantially more secure...


uPNP should be disabled by default and where possible as it is a security 
hazard for those that understand it.  For those that don't it's a compromise 
waiting to happen.

Juniper doesn't support uPNP in the commercial market at all (and even given their 
statement in https://kb.juniper.net/InfoCenter/index?page=content=KB5615 I 
can point out that even in their semi-residential products - ie their small office 
gear doesn't support it either I'd suggest that any support for uPNP is off by 
default and gives a warning if someone tries to enable it.)


My point was simply that sometimes attack come inside your own firewall. Don’t 
naively assume that all attacks are external only; that’s not “defense in 
depth”.

100% agree, was just using the comments as a platform for ensuring 
everyone is on the same page and adding that little more depth where we 
can... :)


--
Michelle Sullivan
http://www.mhix.org/


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-10 Thread Philip Prindeville 


> On Feb 10, 2018, at 6:03 PM, Michelle Sullivan  wrote:
> 
> Paul Oranje wrote:
>> Your aptness for seeing the possible attack vectors warrants your judgement 
>> ...
>> 
>>> Op 10 feb. 2018, om 17:07 heeft Philip Prindeville 
>>>  het volgende geschreven:
>>> 
>>> 
 On Feb 10, 2018, at 3:28 AM, Paul Oranje  wrote:
 
 Wouldn't it be appropriate to disallow password authentication on wan only 
 and allow it on all networks "behind" the router?
>>> Not necessarily.
>>> 
>>> That’s why UPnP is such an issue. A machine inside a firewall gets infected 
>>> by a virus through a download or email... then the first thing the virus 
>>> does is punch holes in the firewall to allow outside scans of the remaining 
>>> hosts.
>>> 
>>> Allowing password logins from an infected host just means that the virus 
>>> has to do slightly more work before it owns the router (ie run a password 
>>> attack).
>>> 
>>> Not substantially more secure...
>>> 
> 
> uPNP should be disabled by default and where possible as it is a security 
> hazard for those that understand it.  For those that don't it's a compromise 
> waiting to happen.
> 
> Juniper doesn't support uPNP in the commercial market at all (and even given 
> their statement in 
> https://kb.juniper.net/InfoCenter/index?page=content=KB5615 I can point 
> out that even in their semi-residential products - ie their small office gear 
> doesn't support it either I'd suggest that any support for uPNP is off by 
> default and gives a warning if someone tries to enable it.)
> 

My point was simply that sometimes attack come inside your own firewall. Don’t 
naively assume that all attacks are external only; that’s not “defense in 
depth”.

-Philip

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-10 Thread Paul Oranje 
Your aptness for seeing the possible attack vectors warrants your judgement ...

> Op 10 feb. 2018, om 17:07 heeft Philip Prindeville 
>  het volgende geschreven:
> 
> 
>> On Feb 10, 2018, at 3:28 AM, Paul Oranje  wrote:
>> 
>> Wouldn't it be appropriate to disallow password authentication on wan only 
>> and allow it on all networks "behind" the router?
> 
> Not necessarily.
> 
> That’s why UPnP is such an issue. A machine inside a firewall gets infected 
> by a virus through a download or email... then the first thing the virus does 
> is punch holes in the firewall to allow outside scans of the remaining hosts.
> 
> Allowing password logins from an infected host just means that the virus has 
> to do slightly more work before it owns the router (ie run a password attack).
> 
> Not substantially more secure...
> 
> -Philip
> 
>> 
>>> Op 9 feb. 2018, om 01:28 heeft Philip Prindeville 
>>>  het volgende geschreven:
>>> 
>>> From: Philip Prindeville 
>>> 
>>> 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.
>>> 
>>> Signed-off-by: Philip Prindeville 
>>> ---
>>> net/openssh/Makefile | 7 +--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/net/openssh/Makefile b/net/openssh/Makefile
>>> index 
>>> 3a19387b0d0110fc5c25d7ffccb524a61c0588c4..7ca61f6ce6d5916016a554b4a283a874e950232c
>>>  100644
>>> --- a/net/openssh/Makefile
>>> +++ b/net/openssh/Makefile
>>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>>> 
>>> PKG_NAME:=openssh
>>> PKG_VERSION:=7.6p1
>>> -PKG_RELEASE:=1
>>> +PKG_RELEASE:=2
>>> 
>>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>>> PKG_SOURCE_URL:=https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ \
>>> @@ -248,7 +248,10 @@ define Package/openssh-server/install
>>>   $(INSTALL_DIR) $(1)/etc/ssh
>>>   chmod 0700 $(1)/etc/ssh
>>>   $(INSTALL_DATA) $(PKG_INSTALL_DIR)/etc/ssh/sshd_config $(1)/etc/ssh/
>>> -sed -r -i 's,^#(HostKey 
>>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' $(1)/etc/ssh/sshd_config
>>> +sed -r -i \
>>> +-e 's,^#(HostKey 
>>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' \
>>> +-e 's,^#PasswordAuthentication yes,PasswordAuthentication no,' 
>>> \
>>> +$(1)/etc/ssh/sshd_config
>>>   $(INSTALL_DIR) $(1)/etc/init.d
>>>   $(INSTALL_BIN) ./files/sshd.init $(1)/etc/init.d/sshd
>>>   $(INSTALL_DIR) $(1)/usr/sbin
>>> -- 
>>> 2.7.4
>>> 
>>> 
> 
> 
> ___
> 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

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

2018-02-10 Thread Philip Prindeville 

> On Feb 10, 2018, at 3:28 AM, Paul Oranje  wrote:
> 
> Wouldn't it be appropriate to disallow password authentication on wan only 
> and allow it on all networks "behind" the router?

Not necessarily.

That’s why UPnP is such an issue. A machine inside a firewall gets infected by 
a virus through a download or email... then the first thing the virus does is 
punch holes in the firewall to allow outside scans of the remaining hosts.

Allowing password logins from an infected host just means that the virus has to 
do slightly more work before it owns the router (ie run a password attack).

Not substantially more secure...

-Philip

> 
>> Op 9 feb. 2018, om 01:28 heeft Philip Prindeville 
>>  het volgende geschreven:
>> 
>> From: Philip Prindeville 
>> 
>> 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.
>> 
>> Signed-off-by: Philip Prindeville 
>> ---
>> net/openssh/Makefile | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>> 
>> diff --git a/net/openssh/Makefile b/net/openssh/Makefile
>> index 
>> 3a19387b0d0110fc5c25d7ffccb524a61c0588c4..7ca61f6ce6d5916016a554b4a283a874e950232c
>>  100644
>> --- a/net/openssh/Makefile
>> +++ b/net/openssh/Makefile
>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>> 
>> PKG_NAME:=openssh
>> PKG_VERSION:=7.6p1
>> -PKG_RELEASE:=1
>> +PKG_RELEASE:=2
>> 
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>> PKG_SOURCE_URL:=https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ \
>> @@ -248,7 +248,10 @@ define Package/openssh-server/install
>>$(INSTALL_DIR) $(1)/etc/ssh
>>chmod 0700 $(1)/etc/ssh
>>$(INSTALL_DATA) $(PKG_INSTALL_DIR)/etc/ssh/sshd_config $(1)/etc/ssh/
>> -sed -r -i 's,^#(HostKey 
>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' $(1)/etc/ssh/sshd_config
>> +sed -r -i \
>> +-e 's,^#(HostKey 
>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' \
>> +-e 's,^#PasswordAuthentication yes,PasswordAuthentication no,' \
>> +$(1)/etc/ssh/sshd_config
>>$(INSTALL_DIR) $(1)/etc/init.d
>>$(INSTALL_BIN) ./files/sshd.init $(1)/etc/init.d/sshd
>>$(INSTALL_DIR) $(1)/usr/sbin
>> -- 
>> 2.7.4
>> 
>> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2018-02-08 Thread Philip Prindeville 
From: Philip Prindeville 

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.

Signed-off-by: Philip Prindeville 
---
 net/openssh/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/openssh/Makefile b/net/openssh/Makefile
index 
3a19387b0d0110fc5c25d7ffccb524a61c0588c4..7ca61f6ce6d5916016a554b4a283a874e950232c
 100644
--- a/net/openssh/Makefile
+++ b/net/openssh/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openssh
 PKG_VERSION:=7.6p1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ \
@@ -248,7 +248,10 @@ define Package/openssh-server/install
$(INSTALL_DIR) $(1)/etc/ssh
chmod 0700 $(1)/etc/ssh
$(INSTALL_DATA) $(PKG_INSTALL_DIR)/etc/ssh/sshd_config $(1)/etc/ssh/
-   sed -r -i 's,^#(HostKey 
/etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' $(1)/etc/ssh/sshd_config
+   sed -r -i \
+   -e 's,^#(HostKey 
/etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' \
+   -e 's,^#PasswordAuthentication yes,PasswordAuthentication no,' \
+   $(1)/etc/ssh/sshd_config
$(INSTALL_DIR) $(1)/etc/init.d
$(INSTALL_BIN) ./files/sshd.init $(1)/etc/init.d/sshd
$(INSTALL_DIR) $(1)/usr/sbin
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev