Re: [openssh-unix-dev] Re: Creating users "on - the - fly"

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux