Nixpkgs: Removing users.extraUsers.<user>.openssh.authorizedKeys.keys does not remove /etc/ssh/authorized_keys.d/<user>

Created on 7 May 2014  Â·  9Comments  Â·  Source: NixOS/nixpkgs

This is because this file is stored as a regular file rather than as a symlink to /etc/static. So the etc updater script doesn't know that it needs to delete it.

bug blocker security nixos

Most helpful comment

All 9 comments

I've added commit 865787e to actually test this in the openssh VM test, and on my Hydra instances this fails with OpenSSH bailing out with:

Authentication refused: bad ownership or modes for directory /nix/store

So, we need a better option than to simply symlink it to the Nix store.

@jwiegley did you test this before pushing?

@lethalman I did not. It seemed simple enough, but I see now that's never a fair assumption.

(triage) what’s the status?

There is an upstream report to allow StrictModes within Match, once this is implemented we can generate the sshd_config like this:

''
  ... some sshd options ...

  ${map (user: ''
  Match User ${user.name}
    StrictModes no
    AuthorizedKeysFile ${pkgs.writeText "authorized-keys-${user.name}" ''
      ${concatStringsSep "\n" user.openssh.authorizedKeys.keys}
      ${concatMapStringsSep "\n" readFile user.openssh.authorizedKeys.keyFiles}
    ''}
  '') usersWithKeys}

  ... other sshd options ...
''

This would be way less racy than adding a "authorized keys file cleaner".

I also thought about patching OpenSSH to prevent mode checking on store paths, but this would actually lead to roughly the same as setting StrictModes to no because an attacker who is able to modify the authorized_keys file in the user's home directory can simply create a file in the Nix store and symlink to it, whereas with StrictModes it's assured that the file is only writable by the corresponding user so an attacker can't do the "symlink to the Nix store" trick to bypass that.

Selectively turning off StrictModes for only a limited set of authorized_keys allows us to still have that check on for user home directories while not checking the modes when we explicitly state the allowed keys by creating a store path along with the main sshd_config.

(triage) still an issue?

Doh! This is bad. (I just switched to this API, thinking "yay, declarative keys!")

Seems to be long fixed:

grahamc@Morbo> sudo nixos-rebuild switch
[sudo] password for grahamc: 
building Nix...
building the system configuration...
these derivations will be built:
  /nix/store/librlnhh1ncb0im17b6wm2x2hwq2xws6-grahamc-authorized_keys.drv
  /nix/store/00khi83m940w76a59jbs9jhg6pak4k64-etc.drv
  /nix/store/0na2nmpssnh5szpxrxa2898dym0ywspy-nixos-system-Morbo-17.03.1700.51a83266d1.drv
building path(s) ‘/nix/store/26092zqbjkgx0cwgf08wsh1a5j1axwva-grahamc-authorized_keys’
building path(s) ‘/nix/store/dl0m1zdw6vibzksscnphi93sd57g01sq-etc’
building path(s) ‘/nix/store/zkf6wlbi0vsw5j20hz0yjpf1gc7f1xzb-nixos-system-Morbo-17.03.1700.51a83266d1’
activating the configuration...
setting up /etc...
setting up tmpfiles

and /etc/ssh/authorized_keys.d/grahamc exists... removed the option, and:

grahamc@Morbo> sudo nixos-rebuild switch
building Nix...
building the system configuration...
activating the configuration...
setting up /etc...
removing obsolete file ‘/etc/ssh/authorized_keys.d/grahamc’...
setting up tmpfiles
grahamc@Morbo> cat /etc/ssh/authorized_keys.d/grahamc
cat: /etc/ssh/authorized_keys.d/grahamc: No such file or directory
Was this page helpful?
0 / 5 - 0 ratings

Related issues

retrry picture retrry  Â·  3Comments

ob7 picture ob7  Â·  3Comments

spacekitteh picture spacekitteh  Â·  3Comments

tomberek picture tomberek  Â·  3Comments

langston-barrett picture langston-barrett  Â·  3Comments