Gluon: New ssh keys after sysupgrade

[mokkin]

If you apply a sysupgrade to a gluon router, new ssh keys are added.
As a standard behaviour this is fine, but if you as a node owner decided to remove the keys or use only your own ones, this should be changed. Especially that's important for big updates via the autoupdater when the user is even not aware of any changes.

[jplitza]

I tend to agree. While it may be okay in certain circumstances to include SSH keys in the original firmware if it is properly communicated, it is a no-go that SSH keys are silently added afterwards by an update – even more so if the owner previously decided to delete them.

[rotanid]

i agree, if you want to deploy ssh keys afterwards, use something like gluon-treatment or another custom package.

[NeoRaider]

One the one hand, I agree that this behaviour might be unexpected. On the other hand, the gluon-authorized-keys package is supposed to be used for own firmware images only anyways (for example during development, or for custom builds without config mode), and never for images that you give to other people.

[viisauksena]

we use it with a special firmware brand, which is used for routers in big refugee locations. There are many routers and debugging quiet convinient this way.
One solution could be - that ssh-keys are checked if they are there - but deactivated via the comment sign # (which could be interpreted as a strong sign that this is intendet)
.. i tend to see this as minor issue ..
only the annoying readding of ssh keys on my home routers, where i tend to test ne FW builds for the refugee context first (and where i disable all the other ssh keys - just in case)

[NeoRaider]

Well, I don't see a problem with changing this behaviour, so an existing authorized_keys file is never modified.

[viisauksena]

@NeoRaider : this is not what you want, because this way you cant add more ssh keys later , while this file is never updated. This way its a clear step back (at least for us in freiburg), again i suggest to check if a key is in the file (no matter how the comment at the end is, or if it is "deactivated" by a leading # ) and based an that add a key from the given keys , or not
in shell it would be something like (free_hand to clarify my point)

for line in $ssh-keys; do 
    if [ $(grep "$line" /etc/dropbear/authorized_keys | wc -l) = 0 ] ; then 
        echo "$line" >> /etc/dropbear/authorized_keys
    fi
done

[kb-light]

Maybe one can add a flag to expert mode like "update authorized_keys via firmware upgrade" and add a note to the config mode as it is already done for the autoupdater.

[viisauksena]

@kb-light - that have to be default - because it should work with autoupdater, and this way you could simply crosscheck in config-mode ... you miss that you have to remove new added keys afterward, which is sad if you was not aware of this (but still minor, if you trust the firmware you are installing)

[kb-light]

@viisauksena : I think there should be a possibility to set the default via site.conf
@viisauksena : what do you mean with "you miss that you have to remove new added keys afterward"? Do you mean, if the default is to update the key and the user disables that functionality, he has to remove the already added keys manually?

Maybe an other idea is to have two files, one for the user added keys (user-keys) and one for the community-keys added/updated via firmware upgrade. So the user can decide, whether he accept the community-keys on his node or not. In the first case, both files are merged to authorized_keys, in the second case just the user-keys are copied to authorized_keys. Additionally there is no problem with deleting old/obsolete/... community-keys, because it is only necessary to remove them from site.conf.

[viisauksena]

"you miss that you have to remove new added keys afterward" means that normaly you would have no idea if with your next sysupgrade (manually) come some ssh keys. And this was just a sidenode.
I see that there are many needs/wishes/ideas by different people, and they are not compatible.

• my moaning results in deactivated keys (by using # ) coming back with sysupgrade
• other people moan because there is no way/method in deleting old keys
  And there were the discussion, already here you come in trouble with expected behaviour ..
  and than : @kb-light have some ideas that this should be configurable in advance

[viisauksena]

any comments from @mokkin as issue starter? beside major change in behaviour i see only this minor "check if key is already there (and dont add again, even if deactivated)" as result

[mokkin]

Well I only want to prevent from adding keys during sysupgrade in cases where the authorized key file was modified manually.

[viisauksena]

but this is fundamental intendet by firmware makers - that there are some ssh keys, if buildin. actually they would be added to your keys. the only unanwered case is , how to handle deactivated/deleted keys.
sysupgrade means that the majority of files would be overwritten, however you could play around with /etc/sysupgrade.conf
(i think in our case i would write a script with which overwrite /etc/dropbear/authorized_keys on reboot with my own. this script would be added to sysupgrade.conf so this is update proof - more a hack but should work)

[NeoRaider]

Okay, basically, there are different opinions how this package should work, so let's just keep this package as is. From our side, this package is only intended for development and first-time installation of your own nodes, a publicly available firmware should _never_ contain it (as you'd be backdooring the nodes).

If you have a different usecase, just use your own package with different handling of existing keys.

[viisauksena]

as i agree with closing, i would add again : this package is also very usefull if you are responsible for a bunch of nodes, so thats the reason we use it as our "refugee"-support branch
where many of these routers are on difficult to reach places.
so beside your intention (firsttime and dev.) there are strong reasons for this package