nixos/pam: Use secure default for sshAgentAuth.authorizedKeysFiles

[nbraud]

Follow-up on #277620, blocked until it is merged.

Description of changes

Change the default value of security.pam.sshAgentAuth.authorizedKeysFiles to [ "/etc/ssh/authorized_keys.d/%u" ].
This breaks backwards-compatibility to fix a security vulnerability: #31611

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
• Tested, as applicable:
  • nixosTests.ssh-agent-auth once Add NixOS test for security.pam.enableSSHAgentAuth #266332 is merged.
• 24.05 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.

[Majiir]

LGTM. Are you planning to merge this for unstable only?

[Majiir]

On one hand, this note could make it more obvious that upgrading could cause a user to lose access to anything protected by pam_ssh_agent_auth. On the other hand, they could always boot up an earlier configuration.

[nbraud]

Right. I'll try and think of a more-explicit wording, thanks <3

[nbraud]

@Majiir What do you think of the new wording?

[Kranzes]

Can't we also use config.services.openssh.authorizedKeysFiles?

[nbraud]

Can't we also use config.services.openssh.authorizedKeysFiles?

No. That's the current behaviour (and remains the default after #277620) but it's insecure-by-default:
services.openssh.authorizedKeysFiles contains %h/.ssh/authorized_keys which is user-writeable.

The reason this is a problem is explained (and illustrated with exploitation steps) in #31611

PS: In case that was unclear, this PR includes the commits that are in #277620, but only 24536c0c0884f694d987b4b445403daa492c7357 is new here.

[nbraud]

LGTM. Are you planning to merge this for unstable only?

I guess? That would be a breaking change for users of the 23.11 branch, in principle, and I expect the previous PR's warning to trigger on the vast majority of insecure configurations.

[nbraud]

Rebased on the current version of #277620

[nbraud]

Rebased after #266332

[nbraud]

Rebased after #266332

[nbraud]

Rebased on current #277620, should be final.

[nbraud]

@ofborg eval

[nbraud]

Rebased on the previous PR's merge commit, so GitHub shows the appropriate commit set and diff. Only change in file is from #276499 being merged :

❯ git --no-pager diff c8f25bf f5ed08f -- nixos/modules/security/pam.nix
diff --git a/nixos/modules/security/pam.nix b/nixos/modules/security/pam.nix
index aedcac44cf71..95aceeaccc5c 100644
--- a/nixos/modules/security/pam.nix
+++ b/nixos/modules/security/pam.nix
@@ -1473,6 +1473,13 @@ in
           `security.pam.zfs.enable` requires enabling ZFS (`boot.zfs.enabled` or `boot.zfs.enableUnstable`).
         '';
       }
+      {
+        assertion = config.security.pam.enableSSHAgentAuth -> config.services.openssh.authorizedKeysFiles != [];
+        message = ''
+          `security.pam.enableSSHAgentAuth` requires `services.openssh.authorizedKeysFiles` to be a non-empty list.
+          Did you forget to set `services.openssh.enable` ?
+        '';
+      }
     ];

     warnings = optional

[nbraud]

eval failure fixed in master
@ofborg eval

[nbraud]

@ofborg test ssh-agent-auth

[nbraud]

Rebased due to merge conflict in release notes. No change.

[nbraud]

@ofborg test ssh-agent-auth

[leona-ya]

Seems to be reasonable and good.

[LeSuisse]

Changes make sense. I played a bit with it locally and everything works as expected.

If nobody complains about it, I'm going to merge this by the end of the week.

[montchr]

When this is released, are there any safeguards (edit: other than a warning explaining the change in abstract) to prevent a system admin from accidentally locking themselves out through misunderstanding the implications? Is there any way to make it crystal clear exactly which authorized keys will be affected on a system?

[LeSuisse]

[...] prevent a system admin from accidentally locking themselves out through misunderstanding the implications? Is there any way to make it crystal clear exactly which authorized keys will be affected on a system?

Unfortunately given that the root cause comes from a default setting with a wrong value I do not see a lot of options.

The probability of being locked out seems to be quite low:

• it requires that the system admin was relying on the behavior this PR is fixing
• the default value was kept
• pam_ssh_agent_auth is the only available way for local auth
• the system admin cannot rollback to the previous generation at boot

This is not ideal but keeping this footgun around is also not :/

[SuperSandro2000]

This should use the renamed option which I think got dropped below and was at some point later re-added #316884