Protect users when disabling users.mutableUsers

[3noch]

I stumbled upon the reality that turning off users.mutableUsers will only use passwords as they are defined in users.users.<user>.password* fields. If passwords are not set, then the user is not given a password and cannot login via password. Unfortunately in my case I did this and lost access to my computer. I had to use a bootable drive to add an SSH key to the root user so I could regain access. (Thanks @cleverca22!)

Two things could have helped in this case:

1. The docs in the manual do not mention how passwords are handled when users.mutableUsers = false. I made the mistake in believing that passwords would remain mutable, which I think is not too idiotic a conclusion because of how the manual is worded.
2. We could add an assert that when mutableUsers = false, each normal user must have either a password or an SSH key. If neither is given, then it truly makes little sense to have the user at all, or at least have them be a normal user.

@grahamc

[edolstra]

We already have this assertion:

      { # If mutableUsers is false, to prevent users creating a
        # configuration that locks them out of the system, ensure that
        # there is at least one "privileged" account that has a
        # password or an SSH authorized key. Privileged accounts are
        # root and users in the wheel group.
        assertion = !cfg.mutableUsers ->
          any id (mapAttrsToList (name: cfg:
            (name == "root"
             || cfg.group == "wheel"
             || elem "wheel" cfg.extraGroups)
            &&
            ((cfg.hashedPassword != null && cfg.hashedPassword != "!")
             || cfg.password != null
             || cfg.passwordFile != null
             || cfg.openssh.authorizedKeys.keys != []
             || cfg.openssh.authorizedKeys.keyFiles != [])
          ) cfg.users);
        message = ''
          Neither the root account nor any wheel user has a password or SSH authorized key.
          You must set one to prevent being locked out of your system.'';
      }

[3noch]

@edolstra I knew it was a good idea! You've confirmed that. ;) I think the issue must be more complicated then. I had 2 users, root and myself. I was in the wheel group and had an SSH key defined, but not a password. Root had neither an SSH key nor a password defined. So when I switched, the only user in wheel had no way to actually access his root privileges because he had no password set.

[edolstra]

Ah, so we should require that root has an SSH key or at least one wheel user has a password, unless security.pam.enableSSHAgentAuth is enabled (because then you can sudo using the ssh-agent).

[3noch]

@edolstra Aha yes that sounds exactly right. And I didn't know about security.pam.enableSSHAgentAuth. That sounds like a great thing to have!

[wizeman]

@3noch In the original description of the problem, did you mean to say when mutableUsers = false rather than mutableUsers = true? Otherwise, I am finding this discussion confusing... :smile:

[3noch]

@wizeman 🤦‍♂️ Yes of course. Thanks for pointing it out. I edited the issue so people don't need to read our comments before it makes sense.

[3noch]

Would someone mind adding this to a milestone and prioritizing it? This seems important.

[clamydo]

I ran in exactly this issue. I have only defined an SSH key for an unprivileged user, nothing else. Now I'm locked out of the system.

Could this be solved, by removing

             || cfg.openssh.authorizedKeys.keys != []
             || cfg.openssh.authorizedKeys.keyFiles != [])

for users in wheel in the assertion above? Forcing that at least one wheel user (or root) has set a password. Having a SSH-key for a wheel user is just not relevant in the context here, is it?

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[3noch]

Still important.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[zarybnicky]

Still relevant, this just bit me twice.

[stale[bot]]

I marked this as stale due to inactivity. → More info