lock password by default

[tcatm]

By default the root password should be locked. It should be possible to set it from configmode (web + telnet).

[sargon]

For my understanding the firmware should run without setting any root password. So disabling any ssh access by default and only activate it when the user is settings a password in configmode.
Furthermore it would be nice to allow to set a ssh key instead of using a password.

[neocturne]

Is it enough to disable telnet and uhttpd by default, or should there be firewall rules that ensure they aren't reachable from the mesh when they are enabled by the node operator?

Considering there is no way to safely login to uhttpd through the mesh (as we don't provide HTTPS support) it should probably be blocked anyways, so going with the firewall rules might be the best solution.

[tcatm]

I think it's enough to disable telnet. SSH won't allow logins when no password is set.

I'll tweak expertmode (part of configmode requiring login) to not allow logins at all when no password is set so that it can only be reached from configmode. If the owner decides to enabled uhttpd during normal operation and set a password that's fine with me as it's their own responsibility.

[neocturne]

I strongly oppose allowing access to the config mode/Luci during normal operation even when a password is set as it is inherently insecure (especially so in our bridged network setup).

[neocturne]

After some testing, I think it would be best to lock the root account to ensure no login is possible without explicitly setting a password. This also gets rid of the annoying "There is no password set on this router. Please configure a root password to protect the web interface and enable SSH." message in the config mode.

If noone is opposed to this solution, I'll take care of it.

[tcatm]

Will it still be possible to access the node via telnet (without password) when in configmode?

[neocturne]

Yes, with a little change to the telnet command that's no problem.

[neocturne]

Hmm, I'm currently pondering about where to put the account locking.

Places where it makes sense:

• gluon-core: ensures that the root account is always locked unless a password is set
• gluon-config-mode: allows accessing the node and setting a password in a secure way

The question is: what is the correct behaviour when we build gluon without the config mode?

1. If we lock the account in gluon-core, we have no means to access the mode at all (besides failsafe mode), unless another (not yet existing package) allows setting a password
2. If we lock the account in gluon-config-mode, we have an unlocked root user, which is potentially a security issue (we might add firewall rules though, but what are the right rules here?)

I'm slightly in favour of option 1., with a "don't to that then" solution to the gluon-without-config-mode issue

[tcatm]

I'd prefer a behaviour that does not depend on the gluon-config-mode. So that's 1. However, there are valid use cases where one might deploy an image without gluon-config-mode (say a larger installation or even a Nook-firmware) but where SSH access is still desirable. Going through failsafe mode would be a hassle.

So, what about adding a gluon-lock-password package? In future versions we could extend it to deploy SSH keys or set a fixed root password.

[neocturne]

I like that solution.