[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

[Jakub Jančo]

Is slow login still present on ssh?
Because we had problem, that ssh login takes about 10seconds and
telnet is instant. It is difference if we do initial bulk setup for
more devices.
If I login to my pc, ssh login takes <1sec.

Thanks for reply.

--
S pozdravom Jakub Janco

Post by 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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[RB]

Post by Jakub Jančo
Is slow login still present on ssh?
Because we had problem, that ssh login takes about 10seconds and
telnet is instant. It is difference if we do initial bulk setup for
more devices.

Experience with SSH breakage tells me that kind of slowness might be
due to the SSHD attempting to use DNS to check the origin system
(OpenSSH's UseDNS flag). It's been a while since I dug into the
OpenWRT SSH config, but is it generating the SSH keys upon first
connection? That might be a source of slowness as well.

[Brent Thomson]

Post by RB
Experience with SSH breakage tells me that kind of slowness might be
due to the SSHD attempting to use DNS to check the origin system
(OpenSSH's UseDNS flag). It's been a while since I dug into the
OpenWRT SSH config, but is it generating the SSH keys upon first
connection? That might be a source of slowness as well.

Slowness probably depends on hardware as well as all the possibilities
listed by others. I have a model of router that always takes 2-3
seconds to initiate an SSH connection, just to set up encryption
(brief, but computationally intensive; happens with every connection).
10 seconds seems really slow, though. Smells like DNS.


--

Brent

[Vittorio G (VittGam)]

Post by Brent Thomson
Slowness probably depends on hardware as well as all the possibilities
listed by others. I have a model of router that always takes 2-3
seconds to initiate an SSH connection, just to set up encryption
(brief, but computationally intensive; happens with every connection).
10 seconds seems really slow, though. Smells like DNS.

It might not be DNS in fact. On AR9331 (MIPS 24k CPU, not that fast...)
starting from Barrier Breaker SSH is pretty slow (3-4 seconds), so on
slower routers the login time can be longer.

If you login with ssh -v, you can see that it waits between

Post by Brent Thomson
debug1: expecting SSH2_MSG_KEXDH_REPLY

and

Post by Brent Thomson
debug1: Server host key: RSA [...]

If you check the CPU usage on the router while the client is waiting for
the reply, you can see that dropbear is at 100%.

Cheers,
Vittorio

[Jakub Jančo]

Vittorio is right. Some seconds I got with disabling testing all my
public keys. I tried add dns to /etc/hosts, but no gain.

It waits where Vittorio wrote. I searched for disabling ciphers but
didnt found anything. Probably it cannot be done.

--
S pozdravom Jakub Janco

Post by Vittorio G (VittGam)

Post by Brent Thomson
Slowness probably depends on hardware as well as all the possibilities
listed by others. I have a model of router that always takes 2-3
seconds to initiate an SSH connection, just to set up encryption
(brief, but computationally intensive; happens with every connection).
10 seconds seems really slow, though. Smells like DNS.

It might not be DNS in fact. On AR9331 (MIPS 24k CPU, not that fast...)
starting from Barrier Breaker SSH is pretty slow (3-4 seconds), so on
slower routers the login time can be longer.
If you login with ssh -v, you can see that it waits between

Post by Brent Thomson
debug1: expecting SSH2_MSG_KEXDH_REPLY

and

Post by Brent Thomson
debug1: Server host key: RSA [...]

If you check the CPU usage on the router while the client is waiting for
the reply, you can see that dropbear is at 100%.
Cheers,
Vittorio
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[Janusz Dziemidowicz]

Post by Vittorio G (VittGam)

Post by Brent Thomson
Slowness probably depends on hardware as well as all the possibilities
listed by others. I have a model of router that always takes 2-3
seconds to initiate an SSH connection, just to set up encryption
(brief, but computationally intensive; happens with every connection).
10 seconds seems really slow, though. Smells like DNS.

It might not be DNS in fact. On AR9331 (MIPS 24k CPU, not that fast...)
starting from Barrier Breaker SSH is pretty slow (3-4 seconds), so on
slower routers the login time can be longer.
If you login with ssh -v, you can see that it waits between

Post by Brent Thomson
debug1: expecting SSH2_MSG_KEXDH_REPLY

and

Post by Brent Thomson
debug1: Server host key: RSA [...]

If you check the CPU usage on the router while the client is waiting for
the reply, you can see that dropbear is at 100%.

SSH time can be greatly reduced by using ECDSA host key. Dropbear can
be compiled with ECDSA support, however:
- it is disabled by default in OpenWRT
- startup script only generates RSA/DSA host keys, ECDSA host key must
be generated manually

Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s
down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not
sure about other architectures.
I can try to send a patch that enables ECDSA by default and fixes the
startup script, if there is any interest. dropbear package size
increases by about 20kB.

[Vittorio G (VittGam)]

Post by Janusz Dziemidowicz
SSH time can be greatly reduced by using ECDSA host key. Dropbear can
- it is disabled by default in OpenWRT
- startup script only generates RSA/DSA host keys, ECDSA host key must
be generated manually
Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s
down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not
sure about other architectures.

Also, I think ed25519 keys and chacha20-poly1305 encryption might be worth
a try. They should be faster than ECDSA + AES on embedded processors, but
they need a relatively recent version of the SSH client (read: possible
problems on Windows and Macs).

[Sami Olmari]

Does Dropbeard support ether? I know OpenSSH does, but default installation
does not use that.

Olmari

Post by Vittorio G (VittGam)

Post by Janusz Dziemidowicz
SSH time can be greatly reduced by using ECDSA host key. Dropbear can
- it is disabled by default in OpenWRT
- startup script only generates RSA/DSA host keys, ECDSA host key must
be generated manually
Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s
down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not
sure about other architectures.

Also, I think ed25519 keys and chacha20-poly1305 encryption might be worth
a try. They should be faster than ECDSA + AES on embedded processors, but
they need a relatively recent version of the SSH client (read: possible
problems on Windows and Macs).
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[Vittorio G (VittGam)]

Post by Sami Olmari
Does Dropbeard support ether? I know OpenSSH does, but default
installation does not use that.

I just checked the changelog[1] and I remembered wrong about chacha20.

Post by Sami Olmari
2013.61test - Thursday 14 November 2013
- ECC (elliptic curve) support. Supports ECDSA hostkeys (requires new keys to
be generated) and ECDH for setting up encryption keys (no intervention
required). This is significantly faster.
another elliptic curve mode with less potential of NSA interference in
algorithm parameters. curve25519-donna code thanks to Adam Langley

By the way, dropbearkey might not be required anymore, and removing it will
improve CSPRNG security... but that's OT here :)

Post by Sami Olmari
- -R option to automatically generate hostkeys. This is recommended for
embedded platforms since it allows the system random number device
/dev/urandom a longer startup time to generate a secure seed before the
hostkey is required.

Cheers,
Vittorio

[1]: https://matt.ucc.asn.au/dropbear/CHANGES

[Vittorio G (VittGam)]

Post by Steven Barth
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

[Vittorio G (VittGam)]

Post by Vittorio G (VittGam)
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

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

Post by Vittorio G (VittGam)

Post by Steven Barth
as of https://dev.openwrt.org/changeset/46809 telnet is no longer part

of

Post by Steven Barth
the base images. As a replacement, it is now possible to login to the

root-

Post by Steven Barth
account via SSH without a password prompt whenever no root password is

set,

Post by Steven Barth
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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[Michael Heimpold]

Post by 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

[Vittorio G (VittGam)]

Post by Michael Heimpold
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...

[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

[Hannu Nyman]

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=0xb0010000, 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: 0x11110000


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: 10000
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

[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

[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

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

[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

Post by 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
-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

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
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel