Re: [OpenWrt-Devel] Removing Telnet

[Steven Barth]

Hello Michael,

that is interesting, though I guess since these are mainly our default
it shouldn't be too hard for someone manufacturing to change the config
and readd a simple init-script for telnetd if that is really required.

Lack of entropy doesn't seem to be too much of an issue here, in fact
in failsafe mode we generate a 1024 bit RSA-key on demand which takes
<2s on my old Buffalo here. Granted its only 1024-bit but still. Now
the regular keys are 2048-bit which takes about a minute which could
be seen as problematic.

However in the verge of making these changes we also removed DSS support
and removed some of the ciphers (3DES, Twofish) and CBC mode in general
as well, so we at least save ourselves the DSS key generation.

In the future we might want to switch to add ed25519 since its more secure
and probably faster than the classical approaches mechanisms here, but we
have to ensure that it is compatible with at least most common SSH clients
out there, mainly probably Putty on Windows and OpenSSH on Linux & OS X.


Cheers,

Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Hannu Nyman]

Steven Barth wrote at Wed Sep 9 08:10:18 CEST 2015:
> Lack of entropy doesn't seem to be too much of an issue here, in fact in 
failsafe mode we generate a 1024 bit RSA-key on demand which takes <2s on my 
old Buffalo here. Granted its only 1024-bit but still. Now the regular keys 
are 2048-bit which takes about a minute which could be seen as problematic.


That time seems to vary by router. I tested yesterday with my ar71xx/WNDR3700 
r46803:
removing the RSA-key before reboot (and thus forcing the dropbear init script 
to generate a new key before launching the actual dropbear process) will 
delay the launch of the dropbear process by some 15 seconds. That can be 
easily seen from the system log by comparing the timestamps and the position 
of dropbear startup message in the log. The 15 second delay was consistent on 
several reboots with r46803.


Running the dropbear key generation manually from console takes only 2-3 
seconds, but then the router is already fully up and has generated more entropy.



Interestingly, right now with r46832, the recent ip/ifconfig changes have 
apparently caused some additional lag to the key generation in a normal boot, 
as the dropbear startup delay with key generation is now 39 seconds. Below 
are two log excerpts showing the impact.
* If RSA key exists, the dropbear startup is consistently at the same place 
right after mtdblock handling.
* If the key needs to be generated, dropbear starts 39 secs later. (log shows 
the sysfixtime clock jump for clarity)


I briefly tested the failsafe mode, and there dropbear ssh seems to be 
reachable some 15-20 seconds after the failsafe mode has been selected (led 
blinks rapidly). That is consistent with the yesterday's observations about 
the key generation at startup.


Reboot, normal, RSA key exists
=
Tue Sep  8 22:40:01 2015 kern.info kernel: [   18.152072] ieee80211 phy1: 
Atheros AR9280 Rev:2 mem=0xb001, irq=41
Tue Sep  8 22:40:03 2015 user.emerg : this file has been obsoleted. please 
call "/sbin/block mount" directly
Tue Sep  8 22:40:04 2015 daemon.err block: mounting /dev/mtdblock4 (squashfs) 
as /mnt/mtdblock4 failed (-1) - No error information

Tue Sep  8 22:40:04 2015 daemon.err block: /dev/mtdblock5 is already mounted
Tue Sep  8 22:40:05 2015 authpriv.warn dropbear[1251]: Failed loading 
/etc/dropbear/dropbear_ecdsa_host_key

Tue Sep  8 22:40:05 2015 authpriv.info dropbear[1251]: Not backgrounding
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_multiport

Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_comment
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - xt_length
Tue Sep  8 22:40:07 2015 daemon.err insmod: module is already loaded - 
xt_multiport
Tue Sep  8 22:40:07 2015 kern.debug kernel: [   26.527131] ar71xx: pll_reg 
0xb8050010: 0x



Reboot, RSA key deleted before reboot
=
Tue Sep  8 22:40:04 2015 daemon.err block: mounting /dev/mtdblock4 (squashfs) 
as /mnt/mtdblock4 failed (-1) - No error information

Tue Sep  8 22:40:04 2015 daemon.err block: /dev/mtdblock5 is already mounted
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_multiport

Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_comment
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - xt_length
...
Tue Sep  8 22:40:36 2015 user.notice SQM: cur_target: auto cur_bandwidth: 1
Wed Sep  9 10:57:12 2015 user.notice SQM: get_target defaulting to auto.
...
Wed Sep  9 10:57:21 2015 authpriv.warn dropbear[3625]: Failed loading 
/etc/dropbear/dropbear_ecdsa_host_key

Wed Sep  9 10:57:21 2015 authpriv.info dropbear[3625]: Not backgrounding
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Removing Telnet

[Ben Franske]

A couple of thoughts on some of the discussion around this:

1) I would be a proponent of a pre-set password, SSH without a password 
is very unusual behavior. I understand that there have been some 
comments "Any preset password is asking for users to
leave it default." I fail to see how this is any more true for a default 
password compared with no password. Having no password is asking for 
people to leave it without any password at all. Therefore I would 
suggest that a preset password is no worse in terms of getting the 
password changed than having no password. In the past the incentive to 
set a password was to enable SSH but that will no longer be the case so 
I see no disadvantage to having a pre-set password (which will provide a 
better user experience as it's more "normal").


2) If there is a great concern about getting people to change passwords 
then there should be a first boot script which launches passwd for them 
the first time they connect. There are disadvantages to this as well no 
doubt but it would be worth discussing if you want to force a password 
set/change.


3) For those looking to run automated device setup scripts... I think 
it's time to come up with new plan, there are lots of options. If you 
are provisioning a large number of devices I would argue you should be 
creating a custom image anyway. That custom image could easily include a 
first boot script which automatically pulls some configuration files 
from an HTTP/HTTPS server or a FTP/TFTP server or any one of the other 
multitude of ways you could do this. Automatic device provisioning is a 
pretty well understood problem (see VoIP phones for example) and easily 
solvable. If you're not currently building custom images it's a bit more 
of a headache, but you probably should be anyway because there are some 
real advantages to it for multiple device initialization anyway.


4) If there is enough interest in automatic provisioning on first boot 
it might be possible to try and build it into the standard OpenWRT image 
too.


-Ben
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Ben Franske]

I'm copying this to the list because it was sent directly to me... There 
are definitely many ways of "encouraging" people to change the password 
which could be explored, another example is the WAN interface could be 
disabled until the password is set. A few more thoughts on something 
like that or the WiFi disable proposed below though:


-Don't just have a feature like WiFi die without an error message 
indicating the password must be changed, again bad user experience (and 
lots of support requests)
-Make sure that the error is clear BOTH in LuCI and the CLI and provide 
instructions for changing the password (e.g. just sending an error to 
the console is not sufficient) LuCI already can detect the null password 
condition as it prompts the user with a banner to set a password, this 
could be adapted to check for a default password and the warn the user 
that some features are disabled until the password is changed


-Ben

On 9/9/2015 6:05 PM, Derek & Vicky wrote:
I agree no password is problematic, so is a default password that 
never gets changed.  So what if the wifi startup script checks the 
md5sum of the /etc/shadow file against the sum it created at startup 
Or predefined value.  This way it won't enable the wifi unless the sum 
changes.


Derek

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Sami Olmari]

IMHO no password is best method until a password is set (like it was with
telnet and now with new paswordless SSH). A default password is just false
sense of security, there is none! Otherwise "encouraging" to set one and
how can be discussed...

 Olmari

On Thu, Sep 10, 2015 at 3:14 AM, Ben Franske  wrote:

> I'm copying this to the list because it was sent directly to me... There
> are definitely many ways of "encouraging" people to change the password
> which could be explored, another example is the WAN interface could be
> disabled until the password is set. A few more thoughts on something like
> that or the WiFi disable proposed below though:
>
> -Don't just have a feature like WiFi die without an error message
> indicating the password must be changed, again bad user experience (and
> lots of support requests)
> -Make sure that the error is clear BOTH in LuCI and the CLI and provide
> instructions for changing the password (e.g. just sending an error to the
> console is not sufficient) LuCI already can detect the null password
> condition as it prompts the user with a banner to set a password, this
> could be adapted to check for a default password and the warn the user that
> some features are disabled until the password is changed
>
> -Ben
>
> On 9/9/2015 6:05 PM, Derek & Vicky wrote:
>
>> I agree no password is problematic, so is a default password that never
>> gets changed.  So what if the wifi startup script checks the md5sum of the
>> /etc/shadow file against the sum it created at startup Or predefined
>> value.  This way it won't enable the wifi unless the sum changes.
>>
>> Derek
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Removing Telnet

[Steven Barth]

Hello everyone,

as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of
the base images. As a replacement, it is now possible to login to the root-
account via SSH without a password prompt whenever no root password is set,
e.g. after a flash without keeping config, factory reset or in failsafe.

We will see how that goes. Let us know if there are any issues.


Cheers,

Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Jonathan Bennett]

Nak on setting a default password. The blank password has served its
purpose well for years now. Any preset password is asking for users to
leave it default. The only problem with blank ssh logins is it removes one
of the ways openwrt encouraged the user to set a password.

A banner that warns about a blank password would be fine, similar to what
Luci does. Any thoughts about forcing a password change on first ssh login?
I haven't thought through the idea fully myself.

On Tue, Sep 8, 2015 at 1:35 PM Vittorio G (VittGam) 
wrote:

> Il 08.09.2015 10:15 Steven Barth ha scritto:
> > as of https://dev.openwrt.org/changeset/46809 telnet is no longer part
> of
> > the base images. As a replacement, it is now possible to login to the
> root-
> > account via SSH without a password prompt whenever no root password is
> set,
> > e.g. after a flash without keeping config, factory reset or in failsafe.
>
> What about empty root password but authorized_keys for root present? This
> behavior is not clear from the patch...
>
> Maybe it would just be better to set the default root password to 'openwrt'
> or 'insecure' or 'change_me!'?
>
> Cheers,
> Vittorio
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Michael Heimpold]

Am Dienstag, 8. September 2015, 10:15:52 schrieb Steven Barth:
> Hello everyone,
> 
> as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of
> the base images. As a replacement, it is now possible to login to the root-
> account via SSH without a password prompt whenever no root password is set,
> e.g. after a flash without keeping config, factory reset or in failsafe.
> 
> We will see how that goes. Let us know if there are any issues.

just for the record, at my last employer, we developed various custom
OpenWrt based embedded devices. During manufacturing process, we
had a stage where the final device was equipped with serial numbers,
mac addresses and so on - we called this stage 'device baptism'.
So was done by logging into the device via telnet, because this was
fast and available nearly immediately after reboot (and because the
somewhat old-fashion production toolsuite only supports telnet, but
not SSH).

I also remember that "long time ago" there were issues because of
not enough entropy available on embedded devices.
Is this still an issue? Should only delay the time when logging in is
possible, right?

So...I'll dry my tears and then go with it :-)

Regards,
Michael
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Vittorio G (VittGam)]

Il 08.09.2015 10:15 Steven Barth ha scritto:

as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of
the base images. As a replacement, it is now possible to login to the root-
account via SSH without a password prompt whenever no root password is set,
e.g. after a flash without keeping config, factory reset or in failsafe.


What about empty root password but authorized_keys for root present? This
behavior is not clear from the patch...

Maybe it would just be better to set the default root password to 'openwrt'
or 'insecure' or 'change_me!'?

Cheers,
Vittorio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Vittorio G (VittGam)]

Il 08.09.2015 20:34 Vittorio G (VittGam) ha scritto:

Maybe it would just be better to set the default root password to 'openwrt'
or 'insecure' or 'change_me!'?


Maybe along with a preauthentication banner that tells the user about the
default password and the fact that it should be changed as soon as possible.

Cheers,
Vittorio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Vittorio G (VittGam)]

Il 08.09.2015 21:31 Michael Heimpold ha scritto:

I also remember that "long time ago" there were issues because of
not enough entropy available on embedded devices.
Is this still an issue? Should only delay the time when logging in is
possible, right?


The dropbearkey key generation will delay dropbear start, so it will
reply with connection refused until it's ready. It would be worth trying
the -R option instead of dropbearkey...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel