Manage ssh public keys?

Manage ssh public keys?

[Joe Hillenbrand]

[-- Attachment #1: Type: text/plain, Size: 88 bytes --]

Is there a way to manage users' ssh public keys via the operating-system
configuration?

[-- Attachment #2: Type: text/html, Size: 109 bytes --]

Re: Manage ssh public keys?

[David Thompson]

Joe Hillenbrand <joehillen@gmail.com> writes:

> Is there a way to manage users' ssh public keys via the operating-system
> configuration?

Our <user-account> type in gnu/system/shadow.scm doesn't provide such a
thing.  Perhaps we could provide some generic facility for specifying
per-user files.

Thoughts?

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Manage ssh public keys?

[Ludovic Courtès]

Joe Hillenbrand <joehillen@gmail.com> skribis:

> Is there a way to manage users' ssh public keys via the operating-system
> configuration?

No (not yet?).  I guess you mean the authorized keys, right?

It would be nice to have something like that, especially for automated
deployment scenarios.  (For multi-user machine scenarios, it may be less
useful: users may prefer to manage authorized keys by themselves rather
than relying on the admin to do that.)

Thanks,
Ludo’.

Re: Manage ssh public keys?

[Joe Hillenbrand]

On Thu, Apr 9, 2015 at 5:00 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
> No (not yet?).  I guess you mean the authorized keys, right?

Yes

> It would be nice to have something like that, especially for automated
> deployment scenarios.

That is specifically the scenario I am building for. I am also trying
to build testing VMs that need to be able to ssh after the images boot
up.

How do you suggests this functionality should be added?

NixOS has the "openssh.authorizedKeys.keys" setting, but I don't think
that translates to Guix.
https://nixos.org/nixos/manual/sec-user-management.html

Re: Manage ssh public keys?

[Ludovic Courtès]

Joe Hillenbrand <joehillen@gmail.com> skribis:

> On Thu, Apr 9, 2015 at 5:00 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> No (not yet?).  I guess you mean the authorized keys, right?
>
> Yes
>
>> It would be nice to have something like that, especially for automated
>> deployment scenarios.
>
> That is specifically the scenario I am building for. I am also trying
> to build testing VMs that need to be able to ssh after the images boot
> up.
>
> How do you suggests this functionality should be added?
>
> NixOS has the "openssh.authorizedKeys.keys" setting, but I don't think
> that translates to Guix.
> https://nixos.org/nixos/manual/sec-user-management.html

No, indeed.

As discussed on IRC, there are several issues, such as the choice of the
SSH implementation (lshd uses ‘lsh-authorize’ to add authorized keys,
not ~/.ssh/authorized_keys.)  That complicates things.

However, as David suggests, we could have a per-account list of files to
install.  I can imagine something like:

  (user-account
    (name "joe")
    ;; ...
    (files `((".ssh/authorized_keys" ,(local-file "my-authorized-keys"))
             (".emacs.d/foo.el" ,(local-file "foo.el")))))

Now, how should that be handled upon ‘reconfigure’?  By just overriding
those files?  Probably, I guess.

Also, should they be symlinks to the store or copies?

Ludo’.

Re: Manage ssh public keys?

[宋文武]

Ludovic Courtès <ludo@gnu.org> writes:

> As discussed on IRC, there are several issues, such as the choice of the
> SSH implementation (lshd uses ‘lsh-authorize’ to add authorized keys,
> not ~/.ssh/authorized_keys.)  That complicates things.
>
> However, as David suggests, we could have a per-account list of files to
> install.  I can imagine something like:
>
>   (user-account
>     (name "joe")
>     ;; ...
>     (files `((".ssh/authorized_keys" ,(local-file "my-authorized-keys"))
>              (".emacs.d/foo.el" ,(local-file "foo.el")))))
>
> Now, how should that be handled upon ‘reconfigure’?  By just overriding
> those files?  Probably, I guess.
>
> Also, should they be symlinks to the store or copies?
How about use symlinks, but:
  - create them if they are not exists.
  - update them if they are symlinks to /gnu/store.
  - warn and do nothing about them if they aren't symlinks to store.

So users won't lost the changes they made.
>
> Ludo’.

Re: Manage ssh public keys?

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> As discussed on IRC, there are several issues, such as the choice of the
>> SSH implementation (lshd uses ‘lsh-authorize’ to add authorized keys,
>> not ~/.ssh/authorized_keys.)  That complicates things.
>>
>> However, as David suggests, we could have a per-account list of files to
>> install.  I can imagine something like:
>>
>>   (user-account
>>     (name "joe")
>>     ;; ...
>>     (files `((".ssh/authorized_keys" ,(local-file "my-authorized-keys"))
>>              (".emacs.d/foo.el" ,(local-file "foo.el")))))
>>
>> Now, how should that be handled upon ‘reconfigure’?  By just overriding
>> those files?  Probably, I guess.
>>
>> Also, should they be symlinks to the store or copies?
> How about use symlinks, but:
>   - create them if they are not exists.
>   - update them if they are symlinks to /gnu/store.
>   - warn and do nothing about them if they aren't symlinks to store.

The problem is that that would be stateful, and thus not reproducible.
So I think conditionals like this are not desirable.

Ludo’.

Re: Manage ssh public keys?

[David Thompson]

Ludovic Courtès <ludo@gnu.org> writes:

> 宋文武 <iyzsong@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> As discussed on IRC, there are several issues, such as the choice of the
>>> SSH implementation (lshd uses ‘lsh-authorize’ to add authorized keys,
>>> not ~/.ssh/authorized_keys.)  That complicates things.
>>>
>>> However, as David suggests, we could have a per-account list of files to
>>> install.  I can imagine something like:
>>>
>>>   (user-account
>>>     (name "joe")
>>>     ;; ...
>>>     (files `((".ssh/authorized_keys" ,(local-file "my-authorized-keys"))
>>>              (".emacs.d/foo.el" ,(local-file "foo.el")))))
>>>
>>> Now, how should that be handled upon ‘reconfigure’?  By just overriding
>>> those files?  Probably, I guess.
>>>
>>> Also, should they be symlinks to the store or copies?
>> How about use symlinks, but:
>>   - create them if they are not exists.
>>   - update them if they are symlinks to /gnu/store.
>>   - warn and do nothing about them if they aren't symlinks to store.
>
> The problem is that that would be stateful, and thus not reproducible.
> So I think conditionals like this are not desirable.

+1

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Manage ssh public keys?

[Joe Hillenbrand]

On Fri, Apr 10, 2015 at 7:21 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> How about use symlinks, but:
>>   - create them if they are not exists.
>>   - update them if they are symlinks to /gnu/store.
>>   - warn and do nothing about them if they aren't symlinks to store.
>
> The problem is that that would be stateful, and thus not reproducible.
> So I think conditionals like this are not desirable.
>
> Ludo’.

Something to keep in mind is what a user means when they add a "files"
argument to user-account. I take this to mean "I want the operating
system configurations to manage this file, not the user", which to me
means, clobber a file if it is already there and symlink it to
/gnu/store. The question then is, what happens when the configuration
changes from having a "files" argument to not having one. What happens
to the links?

Also on the topic of a "files" option, what about managing a
collection of files, like a directory of dotfiles or ~/.emacs? Would
it be possible to use this option with something like "git-fetch"?

Re: Manage ssh public keys?

[Ludovic Courtès]

Joe Hillenbrand <joehillen@gmail.com> skribis:

> Something to keep in mind is what a user means when they add a "files"
> argument to user-account. I take this to mean "I want the operating
> system configurations to manage this file, not the user", which to me
> means, clobber a file if it is already there and symlink it to
> /gnu/store.

Yes.

> The question then is, what happens when the configuration changes from
> having a "files" argument to not having one. What happens to the
> links?

Good point.  I’d say we just remove the symlinks.

> Also on the topic of a "files" option, what about managing a
> collection of files, like a directory of dotfiles or ~/.emacs? Would
> it be possible to use this option with something like "git-fetch"?

It would be possible yes.  Behind the scenes it would use gexp, so any
object whose type has a “gexp compiler” can be used (this includes
<package>, <origin>, and <local-file>.)

I’ll see what I can do if nobody beats me at it.

Thanks,
Ludo’.

Re: Manage ssh public keys?

[David Thompson]

Ludovic Courtès <ludo@gnu.org> writes:

> Joe Hillenbrand <joehillen@gmail.com> skribis:
>
>> The question then is, what happens when the configuration changes from
>> having a "files" argument to not having one. What happens to the
>> links?
>
> Good point.  I’d say we just remove the symlinks.

Agreed, but how do we do the diff such that we know to remove them?

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Manage ssh public keys?

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Joe Hillenbrand <joehillen@gmail.com> skribis:
>>
>>> The question then is, what happens when the configuration changes from
>>> having a "files" argument to not having one. What happens to the
>>> links?
>>
>> Good point.  I’d say we just remove the symlinks.
>
> Agreed, but how do we do the diff such that we know to remove them?

Good point as well!  I guess they may just be left there until someone
removes them.  I don’t think we can actually do better, can we?

Ludo’.