On Sat, Jul 20, 2013 at 3:23 PM, Andy Bradford <amb-fos...@bradfords.org>wrote:
[snip]
> I'm trying to accomplish what I believe Matt Welland was suggesting it
> do, which I did like. Basically, if I have an SSH account named
> ``fossil'' on my server, I can use it to server out as many fossils as I
> like to any given SSH key connecting to the ``fossil'' account.
>
>
I think the ultimate usage I envision might be super-set of what Andy is
describing but I'm not sure. Would the proposed mechanism enable the usage
model I describe below?
My desire is to have many users supported via a single account. Users
upload their public key to the system. There is a single account they
access via ssh/fossil ("fossilscm" or something like that) but the log in
process extracts their user id from the url and authenticates against the
public key they uploaded. This means the fossils are protected by a single
account and that users can only access the fossil via that account.
This is how gitolite works (or at least how it worked when I went through
the install process some time ago).
This is a many-to-many with access controlled by scripts/lookup tables at
the fossilscm account end.
Administration consists of:
1. Adding public key/user name combinations
2. Added users to the access lists
================
>From the gitolite wiki at http://gitolite.com/gitolite/index.html#what:
What is gitolite?
Gitolite is an access control layer on top of git. Here are the features
that most people see:
Use a single unix user ("real" user) on the server.
Provide access to many gitolite users:
they are not "real" users,
they do not get shell access.
Control access to many git repositories:
read access controlled at the repo level,
write access controlled at the branch/tag/file/directory level, including
who can rewind, create, and delete branches/tags.
Can be installed without root access, assuming git and perl are already
installed.
Authentication is most commonly done using sshd, but you can also use http
if you prefer (this may require root access).
> The forced command on the server will be:
>
> command="/usr/bin/fossil gate /tmp/allowed-fossils" ssh-rsa ...
>
> fossil gate will then inspect SSH_ORIGINAL_COMMAND and extract the
> requested fossil repo. If the FILENAME contains the requested repo (and
> perhaps if it is executable and returns successfully), fossil gate will
> then exec ``fossil http /path/to/repo'' otherwise it will exit with an
> error.
>
> This allows you to use the same client SSH key to access multiple remote
> fossil accounts using the same remote SSH account. This allows for a 1
> to many as opposed to 1 to 1 relationship.
>
> It will still be possible for a forced command to be:
>
> command="/usr/bin/fossil http /tmp/file.fossil" ssh-rsa ...
>
> However, this means that you can only ever access that single fossil
> file using that SSH key and SSH account combination.
>
> Thoughts?
>
> Andy
> --
> TAI64 timestamp: 4000000051eb0e0f
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
