customize: virtual packages for build configuration

[pprindeville]

Maintainer: me
Compile tested: x86_64, generic, HEAD (4fdc6ca)
Run tested: same

Description:

Adds root-passwd as a virtual package and CONFIG_TARGET_ROOT_PASSWORD as a variable, allowing images to be built with a root password baked in.

Adds disable-openssh-password-login as a virtual package which forces:

PasswordAuthentication no

in /etc/ssh/sshd_config.

[pprindeville]

@aparcar @bobafetthotmail Heads up on this if you're interested.

[bobafetthotmail]

that's interesting, where do I write the root password to embed in the device(s)?

Also, the no-password-shh-login does not seem to throw errors or stop build if keys for the no-password ssh login aren't found, it just loads a script that changes a configuration. That could lead to locking yourself out.

[pprindeville]

that's interesting, where do I write the root password to embed in the device(s)?

It would look like:

CONFIG_TARGET_ROOT_PASSWD="okqU3/hWHEneQ"

in your .config file and you would generate the hash via:

% echo "text" | openssl passwd -stdin -crypt
okqU3/hWHEneQ
% 

[pprindeville]

Also, the no-password-shh-login does not seem to throw errors or stop build if keys for the no-password ssh login aren't found, it just loads a script that changes a configuration.

That's because there's more than one way around this.

You could also pre-provision user accounts, seed their .ssh/authorized-keys files, and put them in the sudo group and accomplish the same thing.

In general, having packages peek into the configuration of other packages is frowned upon because it makes things less deterministic.

But I'm happy to consider reasonable patches.

[pprindeville]

@yousong @sbyx What do you guys think?

[tripolar]

why not use the "files" overlay? i mean customizations are nice but why not use an existing functionality?

[bobafetthotmail]

why not use the "files" overlay?

Having it as a package makes it standardized and publicly reviewable, which should keep a good quality of the code in these customizations.

With the "files" overlay everyone has to come up with a way that works for him, and does not share or allow review of it (as it lives in a local build system) automatically. This makes for many poor or buggy "solutions".

While for this specific case it might be overkill, I like the idea of virtual packages like these for customizing automatically common things.

[pprindeville]

why not use the "files" overlay? i mean customizations are nice but why not use an existing functionality?

Because that means that I'm stuck with a frozen snapshot of files... if /etc/ssh/sshd_config ever gets updated as part of a CVE fix, then that means I could potentially miss that change and not pick up the fix.

Changing just the line that affects me means that I inherit all the other updates for free (at least for future builds).

[yousong]

Hi, @pprindeville , sorry for the late reply (successfully choked my finger in the weekend ;)

I will probably be a user of the disable-root-passwd-login. It will be better as a default OFF config option of dropbear/openssh package as that will be where I will lookup them up in the first place. To keep them in maintained state as shell commands scattered in the tree will be hard.

The same also goes for preconfiguring root password. The security improvement is marginal, probably good for redistribution of firmware images, but personally I am not a fan of this.

[pprindeville]

It will be better as a default OFF config option of dropbear/openssh package as that will be where I will lookup them up in the first place.

I originally tried that PR 5520 but it wasn't well received:

#5520 (comment)

so we keep going back and forth.

[yousong]

@pprindeville My advice is that if this is really important to be in the repo, improve and try your best to make it happen. Otherwise, just have it in your local repo. No disappointment or discouragement. That's the distributed, decentralized way of git workflow I liked very much ;)

[neheb]

@pprindeville Is this still relevant? If so, please rebase against current master.