Disable SSH password logins by default

[bgilbert]

For coreos/fedora-coreos-tracker#138. We don't support sshd_config fragments yet, so the only way to override this with Ignition is by writing a ConditionFirstBoot=true unit Before=sshd.service that runs sed over sshd_config. But it is possible to override it, so let's start testing with this configuration.

[ajeddeloh]

Is this something that is coming to sshd?

Edit: I can't read backlog. https://bugzilla.mindrot.org/show_bug.cgi?id=2468#c8

[bgilbert]

coreos/fedora-coreos-tracker#138 (comment) is also an option.

[ajeddeloh]

LGTM

[dustymabe]

LGTM.. but this does make my head hurt when thinking about upgrading to f31 where the default config will change and also updating to sshd_config fragments when that is available. i.e. are our existing systems going to get the changes or are they going to keep this config as shipped?

[jlebon]

i.e. are our existing systems going to get the changes or are they going to keep this config as shipped?

Hmm not sure I follow. It should be just like any other config changes, right? IOW, once fragments are supported, it should be safe to drop this snippet in favour of a fragment drop-in. The drop-in will be added on system updates, and unless users modified their sshd_config locally, the main config itself as well will be updated.

[bgilbert]

Considering the cases:

• If we're still carrying this postprocess fragment by F31 we'll update it for the Fedora changes. The net result should be:
  • no behavior change for users with unmodified configs (who will then get the new one), and
  • no behavior change for users with modified configs (who will keep the modified old one).
• The key point about config fragments is that the user can use them to override our defaults, so
  • we might choose to continue putting our changes in sshd_config even when fragments become available.
  • If we choose to move our changes to a fragment,
    • we're fine if the user has not customized their sshd_config.
    • If the user removes our changes and we then move them to a fragment, we could end up overriding their customizations, which would be bad.

So if we want to move our changes to a fragment, we should probably do it before the stable release.