Re: Creating / Removing users "on the fly"

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


Hi Simon,

Thanks for suggesting some things.  I've currently got a gitolite
server running which does exactly those things.  The difference is
that on the git server, there are a few hundred users.  On this
application there could be MANY more..  Now - I haven't scaled that
far yet, and don't want to over-engineer it too much. But if I can
avoid the trouble later, I'd like to try.

So - gitolite and those people just slap it in the authorized_keys
file, and that file starts to get really long.

So - I thought, ok, I'll use the SSH hook to call a script to get the
authorized_keys. So that would work.  But that only works if the user
already exists on the system.  If it doesn't - it doesn't even get as
far as the SSH key authentication.

Hence , the desire to try and find a way to "create" the user before I
get to ssh.

Someone just recenlty suggested something about
And maybe that will work... Not sure.

This was what I saw:
And it sortof does what I wanted - it adds the user. I would not need
to query for a password or anything, just get the keys from a
webservice.  But even in this - the user is still created in the users
table... bleck.

I'm digging into the NSS stuff more now.. We'll see.


On Fri, Feb 6, 2015 at 1:05 PM, Simon McVittie
<simon.mcvittie@xxxxxxxxxxxxxxx> wrote:
> On 06/02/15 16:53, Cary FitzHugh wrote:
>> I've got a situation where I have a very large number of "users", one
>> where I can't be sure all my user accounts would fit on a single machine.
>> Additionally - all the users are going to do is set up reverse tunnels.
>> They can only auth via the authorized_keys as well.  And they don't
> They don't what? Execute commands?
> It sounds to me as though you could perhaps give them all access to the same
> unprivileged uid (similar to the way all git pushes to github go via
> ssh://git@xxxxxxxxxx), and use "forced commands" in the authorized_keys file
> to restrict them to setting up port-forwarding but not terminals, command
> execution or whatever. Confining that unprivileged uid to a very restrictive
> chroot or container would probably also be a good idea. No PAM required,
> except possibly for rlimits and chroot.
> Related:
>     S
> --
> Simon McVittie
> Collabora Ltd. <>
> _______________________________________________
> Pam-list mailing list
> Pam-list@xxxxxxxxxx

Pam-list mailing list

[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux