dropbear: disable password logins for root.

[mobinmob]

General

• This is a new package and it conforms to the quality requirements

Have the results of the proposed changes been tested?

• I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
• I generally don't use the affected packages but briefly tested this PR

This PR disables password logins for root by using the -g switch in the runit service. The change follows the default policy for openssh.

[ericonr]

I think this warrants an INSTALL.msg, at least. I'm not sure about policy (following openssh default vs changing a configuration like that), however. @void-linux/pkg-committers thoughts?

[ahesford]

I'm inclined to keep the service as is. The -F is required for proper operation as a runit service. I assume -R is a no-op if keys are already present, making that flag a harmless way to make things "just work" in a fresh installation. Any other flags cause behavior to deviate from defaults and can already be overridden in $OPTS.

(If any change were to be made, I'd move -F out of $OPTS and force its presence to simplify the process of adding non-default flags.)

[Vaelatern]

Someone might be relying on this in an embedded service. At best this warrants a line in the void-docs.

[mobinmob]

@ericonr I will write an INSTALL.msg ;)
@ahesford Ι fully agree with getting -F out of $OPTS. I am using the same logic in the 66 services. I think there are others runit services in the repo that can benefit from something similar - that is seperation of optional and mandatory switches. Key generation is a part of all three ssh services in the repo (openssh, dropbear, tinyssh).
@Vaelatern It is ultimately a matter or policy. Disabling password login for root is a good practice. Users can rely on all sorts of things :)

[ericonr]

@mobinmob the issue here is that we'd be changing the service behavior on an update, and it's possible someone might miss it and get locked out after a reboot. Documenting that the default service allows root login might be the safest way forward (though I'd suggest keeping it disabled in your own services).

Does dropbear work fine if you specify -F twice, as well? Otherwise someone with a conf file might have issues.

[mobinmob]

@mobinmob the issue here is that we'd be changing the service behavior on an update, and it's possible someone might miss it and get locked out after a reboot. Documenting that the default service allows root login might be the safest way forward (though I'd suggest keeping it disabled in your own services).

I am aware of that danger. I believe that having the same defaults as the de-facto standard implementation has merits.
Will a comment in the run file proposing the -g flag be adequate documentation?

Does dropbear work fine if you specify -F twice, as well? Otherwise someone with a conf file might have issues.

I just checked. It produces an error in the log (Not backgrounding) for the second -F switch but works and other switches work as they should.

Edit: Αctually the log output is the same with either one or two -F switches. Nothing changes ;)

[Vaelatern]

INSTALL.msg noting a change isn't enough. This can really break someone's workflow, or break devices out there without other easy access.

[mobinmob]

INSTALL.msg noting a change isn't enough. This can really break someone's workflow, or break devices out there without other easy access.

I get that :p
I am trying to find out what is the best way to document that the service allows password logins for root and suggest -g in order to follow what openssh does. Is a comment in the service and/or in an INSTALL.msg enough to accomplish what @ericonr suggested?

[Piraty]

back when i did this for openssh (5ce7496, #17596, void-linux/void-mklive#100), only one person complained in IRC but of course admitted that the move was fine to do and their (password login based ) setup was not the best

[Piraty]

I am in favor of merging this. objections @Vaelatern ?

[Vaelatern]

Strongly opposed to merging as-is.

It's a good flag. We should have had it enabled from the beginning. But we didn't.

I think it's not possible to safely migrate users in this context.

[the-maldridge]

Seconded, this is an incredibly bad idea, we can't change flags that would permanently lock out a user like this. We can add it as an INSTALL.MSG if you want, but changing the config on this package now isn't an option.

[Piraty]

hinting about the intended change in INSTALL.msg for a predefined period (6m? 1y?) appears reasonable to me, Void used such similar periods for similar changes before

[Vaelatern]

Dropbear users may be in embedded scenarios where any predefined period may miss someone. 5 years would feel like the minimum.