armbian-firstrun: Optionally skip OpenSSH host key regeneration

[davidandreoletti]

Description

Context

systemd's cloud-init.target and armbian-firstrun.service will be started concurrently (both are wanted by multi-user.target). Both will try to create SSH host keys by default:

• armbian-firstrun will always delete SSH host keys and then generate new ones
• cloud-init.target (by default) will always delete SSH host keys and then generate new ones.

Problem

When one must run armbian-firstrun and cloud-init, there is no deterministic ordering between the 2 files execution and therefore no one can guarantee which will be last to setup OpenSSH host keys. In my current scenario, host keys are explicitly setup in cloud-init and I would expect armbian-firstrun to not delete keys + no ssh host key generation.

Implemented Solution

armbian-firstrun support user defined boolean setting to optionally regenerate SSH host keys in armbian-firstrun:

• false: no ssh key deleted + no ssh host key generated.
  • Allows cloud-init to take over this task and do it deterministically.
• true (or undefined): ssh host key deleted + generated (compatibility: current armbian behaviour)

Documentation summary for feature / change

If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation". You are welcome to open a PR to documentation or you can leave following information for technical writer:

• short description

armbian-firstrun: Optionally skip OpenSSH host key regeneration

• summary

To skip armbian-firstrun's OpenSSH host keys deletion + regeneration (eg: to let cloud-init set the SSH host keys):

• define OPENSSHD_REGENERATE_HOST_KEYS=false in the /path/to/userpatches/config-*.conf file used by ./compile.sh to build the image.

To execute armbian-firstrun's OpenSSH host keys deletion + regeneration:

• define OPENSSHD_REGENERATE_HOST_KEYS=true in the /path/to/userpatches/config-*.conf file used by ./compile.sh to build the image OR do not define OPENSSHD_REGENERATE_HOST_KEYS at all.

• example of usage

See summary section.

How Has This Been Tested?

• qemu-uefi-x86 board: build with OPENSSHD_REGENERATE_HOST_KEYS=false and expect armbian-firstrun to not delete ssh host keys and not regenerate ssh host keys
• qemu-uefi-x86 board: build with OPENSSHD_REGENERATE_HOST_KEYS undefined (most common setup for everyone) and expect armbian-firstrun to delete ssh host keys and regenerate ssh host keys

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings

[davidandreoletti]

@igorpecovnik I can't assign a reviewer. So pinging you :-)

[rpardini]

IMHO: For cloud images, the whole firstrun should be disabled.

My userpatched cloud extensions (not the one that was merged) simply remove it completely.

[davidandreoletti]

IMHO: For cloud images, the whole firstrun should be disabled.

My userpatched cloud extensions (not the one that was merged) simply remove it completely.

@rpardini My setup is atypical where I build an image for each of the following hardware:

• Cubietruck board
• x86-64 min pc
• x86-64 virtual machine

All 3 shares some common config, all setup via cloud-init.

Now, cubietruck has a community maintained image and armbian-firstrun has cubietruck only code my project requires.

Hence the need for an armbian-firstrun + cloud-init solution I proposed.

When my Cubietrucks die, armbian-firstrun will be disabled in my setup and perhaps will migrate to your cloud-init extension if it becomes public :-)

Right now, the proposed PR allows one to optionally disables a small code path in armbian-firstrun.

[rpardini]

armbian-firstrun has cubietruck only code my project requires.

Interesting. That definitely shouldn't be done there; same code could be converted into some hook in the board file, that would ship the image with that service pre-enabled (and would thus be started on boot).