Gluon: Setting authorized_keys results in unauthorized access

[yanosz]

Bug report

What is the problem?
Setting authorized_keys = { 'ssh-rsa AAAA ...} and using gluon-authorized-keys results in ssh-access for root without any authentication.

What is the expected behavior?
SSH-Access requires authentication, with the specified keys being accepted.

Gluon Version:
2018.2.x , master

Site Configuration:
https://github.com/FieldTracks/gluon-site-config

Custom patches:
gluon-wlan-encrypt-psk (c.f. https://github.com/yanosz/gluon/commit/3aec1963dba2bb218a00472847731546d4db4f83) - I don't think it matters.

[kevin-olbrich]

At least for my nodes, this is not reproducible.

Did you forget to include "lock-password" in your site.mk? (Seems to be missing in the repo).
Without that package, the nodes allow root access without any password (tested with skip setup images in 2017.x).

[ecsv]

Some extra information to the statement from @kevin-olbrich:

So you can now argue in many ways but I would guess that yanosz expected following dependency in gluon-authorized-keys:

diff --git a/package/gluon-authorized-keys/Makefile b/package/gluon-authorized-keys/Makefile
index 2995107a..02bfaf15 100644
--- a/package/gluon-authorized-keys/Makefile
+++ b/package/gluon-authorized-keys/Makefile
@@ -7,7 +7,7 @@ include ../gluon.mk

 define Package/gluon-authorized-keys
   TITLE:=Fill /etc/dropbear/authorized_keys from site.conf
-  DEPENDS:=+gluon-core
+  DEPENDS:=+gluon-core +gluon-lock-password
 endef

 $(eval $(call BuildPackageGluon,gluon-authorized-keys))

But it is not there and it is not documented anywhere that you should enable gluon-lock-password when you enable gluon-authorized-keys.

Most people just have it implicitly enabled because they have (gluon-)setup-mode enabled.

[yanosz]

Thanks for the feedback - that's fast :).

gluon-lock-password is new to me. I checked the docs twice and and asked on irc. Searching for "lock-password" in the docs has no match either.

@ecsv Manually applying the patch fixes the issue. Introducing a dependency like this looks very reasonable to me. Thanks! You're correct about the missing config mode - my configuration is rather unique, I guess.

Please let me know, when this patch is merged - I'd like to do a re-test, then.

[mweinelt]

@ecsv Care to create a pull request?

picked. thanks!

[mweinelt]

Also backported to v2018.2.x in 2280cb3a09ea4eb2b4c68154f60fd7d7cc9dee80.

[yanosz]

Confirmed - both https://github.com/freifunk-gluon/gluon/commit/2280cb3a09ea4eb2b4c68154f60fd7d7cc9dee80 and https://github.com/freifunk-gluon/gluon/commit/2eb15bac0e974385b6b49d3c9e74f623d3d63c3f result in fixed installations.

[Adorfer]

results in ssh-access for root without any authentication.

can't reproduce in 2018.2.2.
pleas sum up the situation for old fw. What is the race condition to stubmle into this.

[rotanid]

depends on certain packages:
"using gluon-authorized-keys" - without using gluon-lock-password

[Adorfer]

and "gluon-lock-password" is only installed automatically with which packages in the site.mk enabled?
Or has it to be included "explicitly" in the site.mk, otherwise the builds are vulnerable?

[NeoRaider]

@Adorfer Builds that include the config mode are fine.

[yanosz]

To make sure that you're not effected, SSH to your node and execute:

if [ -f /lib/gluon/upgrade/100-lock-password ]; then echo "You are not affected"; else echo "You are AFFECTED"; fi