sshd: AuthorizedKeysCommand permissions problem

[christianlask]

Describe the bug

I tried to use an AuthorizedKeysCommand in the configuration of the SSHd to obtain the public key of a user that tries to login from a LDAP server.

This does not work, though, because SSHd has fairly strict requirements with regard to the permissions of the executable that is the AuthorizedKeysCommand. Those lead to the following error:

Aug 04 11:50:37 jupiter sshd[834]: error: Unsafe AuthorizedKeysCommand "/nix/store/a55lgi2qlrar4ppwllbhk2wl4xby54vc-ldap-sshkey/bin/ldap-sshkey": bad ownership or modes for directory /nix/store

ldap-sshkey is in this case a custom package containing a shellscript that uses ldapsearch to obtain the SSH keys from the ldap server. (When called manually, I can confirm that the script works as intended.)

The permissions are as follows:

# stat -c '%A %U %G' /nix/store/a55lgi2qlrar4ppwllbhk2wl4xby54vc-ldap-sshkey/bin/ldap-sshkey
-r-xr-xr-x root root

Those should be okay. The problem is, however, that SSHd checks the whole path. And /nix/store itself has the following permissions:

# stat -C '%A %U %G' /nix/store
drwxrwxr-t root nixbld

Those are alas not okay. Hence the error message above.

I am not sure how to enable AuthorizedKeysCommand without some tricky workaround. The way I did it now (install a package as systemPackage and reference it in the SSHd configuration looks clean and correct to me, but does not work.

This does not work when using services.openssh.extraConfig to add the AuthorizedKeysCommand configuration, nor does it work when using the option services.openssh.authorizedKeysCommand introduced with #82413.

To Reproduce
Steps to reproduce the behavior:

1. Add some ${ssh_key_obtaining_package}/bin/executable to services.openssh.authorizedKeysCommand
2. Rebuild NixOS.
3. Try to login using SSH and obverse the log.

Expected behavior
A clear and concise description of what you expected to happen.

I would expect the SSHd to use the given authorizedKeysCommand to obtain the public SSH key for that particular user and grant access based on that.

Notify maintainers
@aanderse

Metadata

# nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.54, NixOS, 20.09pre236721.840c782d507 (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(root): `"nixos-20.09pre236721.840c782d507"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[aanderse]

See nixos/modules/services/misc/sssd.nix for an example. This is configuration I include in my nixops network for every machine:

    environment.etc."ssh/auth" = {
      mode = "0555";
      text = ''
        #!${pkgs.stdenv.shell}
        . /etc/ssh/auth.env
        ${pkgs.openldap}/bin/ldapsearch \
          -H "$LDAP_URI" \
          -w "$LDAP_PASSWORD" \
          -D "$LDAP_BIND_DN" \
          -b "$LDAP_BASE_DN" \
          -o ldif-wrap=no \
          "(sAMAccountName=$1)" sshPublicKeys | ${pkgs.gnused}/bin/sed -n 's/^[ \t]*sshPublicKeys:[ \t]*\(.*\)/\1/p'
      '';
    };

    deployment.keys."auth.env" = {
      user = "nobody";
      group = "nogroup";
      permissions = "0400";
      destDir = "/etc/ssh";
      keyFile = ../keys/auth.env;
    };

[aanderse]

@hiberno does my comment help at all?

[christianlask]

@aanderse I completely forgot to reply. That was rude, I am sorry about that.

Yes, in a way your reply helped. We implemented a similar workaround now. But it still is a workaround in a way, since we needed to place a executable shell wrapper into /etc/ to make everything work.

It might make sense to update the documentation of the option services.openssh.authorizedKeysCommand such that users are informed about the fact that the authorizedKeysCommand cannot reside in the /nix/store/... (if multi-user is enabled) due to permission checks the SSHd does on that command. Or am I mistaken?

[aanderse]

I'm glad that helped. Great idea. Are you able to draft up a simple PR to help out? I'm stretched a bit thin at the moment and would really appreciate the assist.

[stale]

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

[vikanezrimaya]

Still important. While the workaround works, it would be nice to incorporate it into nixpkgs directly.

[aanderse]

im not sure what you mean by that? You need to provide a command to this option and make sure that the command isn't a symlink. The only addition at this point would be to point this out in documentation.

What were you thinking?