[24.11] nixos/ssh: disable authorizedKeysInHomedir by default

[nbraud]

Split-off from #279894 to avoid a breaking change late in 24.05's release cycle.

Do not merge before staging stops being included in the release (not before 2024-05-15 AoE)

Description of changes

• Default services.openssh.authorizedKeysInHomedir to false
  By request of maintainer, and would prevent future issues similar to pam_ssh_agent_auth allowing users to define own ssh pubkey #31611
• Make the default depend on stateVersion
  Causes an eval failure on @ofborg
• Document the breaking change in a release note.
  The 24.11 release notes file doesn't exist yet.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS test(s) openssh
• 24.11 Release Notes
  • (Module updates) Added a release notes entry if the change is significant
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[pbsds]

i assume including #309368 is a mistake, but the sshd and release note diff LGTM!

[nbraud]

i assume including #309368 is a mistake

Oops, it was indeed unintended!

I'm not even sure how I manageds that one, probably branched out after testing that PR, and forgot to specify I was branching from master.
PS: Figured it out, I simply forgot I needed to branch off staging instead 😅

[nbraud]

@mkg20001 I don't think this is mergeable yet, staging won't diverge from the current release until the 15th
PS: The change documentation would also need to be moved into 24.11's release notes

[nbraud]

Rebased to address merge conflict, and add the release note in 24.11. This is now ready for review & merge.

PS: Accidentally introduced some extra whitespace in the release note, now fixed.

[nbraud]

@ofborg test openssh

[SuperSandro2000]

I do not think that we can ever change this default without causing major breakages and potentially causing tremendous damage. Even if we announce this in all places, we probably do not reach enough people that absolutely need to know this and lock them out of there machines. There is also a scenario where people might need to physically remove the root disk from there server after this change, to allow logging back in:

• no user password is set/allowed to log in
• boot parameter cannot be edited
• the generation before this got already garbage collected
• the only ssh key is in their home directory

[SuperSandro2000]

just to block merges until further discussion has happened

[winterqt]

If we wanted to go forward with this change, we could warn on the current default value for two releases (12 months), and then make the switch in 25.11.

[nbraud]

I do not think that we can ever change this default without causing major breakages and potentially causing tremendous damage. Even if we announce this in all places, we probably do not reach enough people that absolutely need to know this and lock them out of there machines.

Since this was spun out in a separate PR, there's probably a lot of context which isn't obvious at first glance:

• the option was introduced because the current behaviour is a root cause for security issues like pam_ssh_agent_auth allowing users to define own ssh pubkey #31611 ;
• the SSH maintainer requested for the default to be changed when I introduced the option ;
• I already pushed the change back to avoid breaking things in 24.05 ;
• I already tried making the default dependent on stateVersion, which would address ~all those concerns... but it causes an evaluation error on ofborg:
  apparently, the darwin builders' configuration pull in the OpenSSH NixOS module, but their configuration is also not supposed to depend on stateVersion (and a check enforces that)
  In any case, that would be my prefered option, and is listed as a task item in the PR description

[nbraud]

If we wanted to go forward with this change, we could warn on the current default value for two releases (12 months), and then make the switch in 25.11.

Or fix the issue preventing the default to depend on stateVersion, presumably.