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
