openssh unix dev - Feb 2015 - Re: Creating users "on - the - fly"

This is a good suggestion - and maybe I'm not totally clear on the
restrictions...

So - in these situations gitolite will actually append things to your
authorized_keys file.  Which can get very long. And after a while - it
gets *very* long. I think I saw comments that it should be limited to
about 20k or so. And around 20k the look up times are in the seconds.
So that wouldn't be enough for me.  I have another service in my
system which uses gitolite, and it works fine - but it doesn't seem to
be able to authenticate a ginormous number of users.

So - I figured that I could use the ssh-keys command to request only a
subset of keys (from a service or something) and that would enable ssh
to auth much faster.

However - as I got into that - I realized that I have no way to "find"
just the keys for a single user.  Since the only argument to that ssh
keys command, is the username.  It's not HTTP so I couldn't point at a
subdomain and use that to look up the information.

Hence my current (potential dead-end) path of trying to let users
access via their username , which then lets me look up their
authorized_keys.  Of course, now I run into the "user doesn't
exist"
issue..

:(

On Fri, Feb 6, 2015 at 1:21 PM, David Bronder <david-bronder at uiowa.edu>
wrote:
> What about doing something like is popular on some git services, where
> instead of having actual accounts for each user, all the users log in with
a
> single account but different keys?  You then govern their access/behavior
> based on which key is used to authenticate.
>
> =Dave
>
>
> On 02/06/2015 12:10 PM, Cary FitzHugh wrote:
>> I guess I didn't want to litter the users table either - it just
seems
>> "wrong" to be actually adding things to the host when it is
really so
>> transient.  It feels like it should be LDAP-ish.  Just ask the server
>> for the keys and do a one-off authentication.  But I've seen even
LDAP
>> creates the user directories.
>>
>> I see that 2.6 kernels can have some 4B users, which should last me a
>> while.   But it is a bit more work and plumbing to try to keep things
>> in sync.
>>
>> I'm a bit / very idealistic though - so I guess I'll keep
rooting
>> around.  I'm ok writing a PAM module if that's what I needed. 
But I
>> have a feeling there's a good bit more to it. And without someone
know
>> "knows " - that can be a very long rabbit trail :)
>>
>> Hrm....
>>
>>
>>
>> On Fri, Feb 6, 2015 at 12:52 PM, Daniel Kahn Gillmor
>> <dkg at fifthhorseman.net> wrote:
>>> On Fri 2015-02-06 12:41:38 -0500, Cary FitzHugh wrote:
>>>> The trouble is that the user isn't created on the machine
beforehand.
>>>> But I actually don't want the user created, b/c I don't
want to litter
>>>> all these servers with little user directories.    Users may be
>>>> transient as well - so littering the directories of these
machines
>>>> with tons of data just causes many other problems (running out
of
>>>> inodes, disk-space, etc).
>>>
>>> If this is your only concern, most systems don't require that a
user
>>> have a unique home directory at all.  You could create a
/home/nobody
>>> which is unusable by anyone, and populate the systems's user
table with
>>> users (maybe via some sensible nameservice switch module) pointing
at
>>> that directory as their homedir.
>>>
>>> In other words, i don't think this is an ssh problem, it can be
solved
>>> directly in other parts of your OS.
>>>
>>>          --dkg
>>
>
> --
> Hello World.                                David Bronder - Systems
Architect
> Segmentation Fault                                      ITS-EI, Univ. of
Iowa
> Core dumped, disk trashed, quota filled, soda warm.   david-bronder at
uiowa.edu

On Fri 2015-02-06 13:38:29 -0500, Cary FitzHugh wrote:
> However - as I got into that - I realized that I have no way to
"find"
> just the keys for a single user.  Since the only argument to that ssh
> keys command, is the username.  It's not HTTP so I couldn't point
at a
> subdomain and use that to look up the information.
You may be interested in the bug report "extend the parameters to the
AuthorizedKeysCommand":

  https://bugzilla.mindrot.org/show_bug.cgi?id=2081

hth,

        --dkg

>> However - as I got into that - I realized that I have no way to
"find"
>> just the keys for a single user.  Since the only argument to that ssh 
>> keys command, is the username.  It's not HTTP so I couldn't
point at a
>> subdomain and use that to look up the information.
>You may be interested in the bug report "extend the parameters to the
>AuthorizedKeysCommand":
 > https://bugzilla.mindrot.org/show_bug.cgi?id=2081


Why not have the Authorized Keys Command  be a script that figures out  the
domain from the username?