[Nix-dev] [PATCH] authorized_keys in users.extraUsers

[Nicolas Pierron]

2011/10/18 Ludovic Courtès <ludo at gnu.org>:
> Hi,
>
> "Rickard Nilsson" <rickard.nilsson at telia.com> skribis:
>
>> Den 2011-10-17 14:04:46 skrev Nicolas Pierron
>> <nicolas.b.pierron at gmail.com>:
>>
>>> Hi,
>>>
>>> On Sun, Oct 16, 2011 at 21:28, Rickard Nilsson
>>> <rickard.nilsson at telia.com> wrote:
>>>> I've written a patch to users-groups.nix that allows me to specify the
>>>> contents of a users ~/.ssh/authorized_keys file like this:
>>>>
>>>>  users.extraUsers = [
>>>>    { name = "myuser";
>>>>      description = "";
>>>>      group = "users";
>>>>      home = "/home/myuser";
>>>>      createHome = true;
>>>>      useDefaultShell = true;
>>>>      authorizedKeyFiles = [
>>>>        "/etc/secrets/someotheruser.id_dsa.pub"
>>>>      ];
>>>>    }
>>>>  ];
>>>>
>>>>
>>>> I can also specify keys directly with the authorizedKeys attribute,
>>>> instead
>>>> of referring files. If there are existing keys in authorized_keys they
>>>> will
>>>> be left alone.
>>>>
>>>> Is this something that others find useful? Does it make sense to put it
>>>> in
>>>> users.extraUsers, or is it too messy? Maybe there is a place for a more
>>>> general home.<username>.authorizedKeys configuration? What do you think?
>>>
>>> I think users.<name?>.authorizedKeys is good place for configuring it.
>>>  But I guess you did not put the modifications into sshd.nix
>>> expression.  So you will have to extend the users option from another
>>> module because the .ssh/authorized_keys is related to sshd.  (see
>>> loaOf/attrsOf in nixpkgs/pkgs/lib/types.nix) Upstart & filesystems are
>>> already doing such a thing.
>>
>> I'm not sure I understand. Do you say that I should put the modification
>> into sshd.nix?
>
> I think Nicolas was referring to the fact that these files are only of
> interest to the OpenSSH daemon, and not to other SSH implementations
> such as GNU lsh.
>
> So you would want to make sure the ‘authorizedKeys’ option is accepted
> if and only if ‘services.openssh.enable’ is true, for instance, and/or
> rename it to ‘user.<name>.openssh.authorizedKeys’.

The option should always be accepted but the value may not be used if
you don't enable openssh.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/