> I am  still trying to  wrap my head around  how fossil works  with SSH
> though. What is best practice for setting it up?

Best practice is what works for you and the group of people for whom you
are setting this up.

By default, Fossil with SSH behaves just like any other Unix environment
where you  use SSH.  For example,  if you  have a  document on  a remote
system and you have  5 people that want to edit  that document using vi,
what would  you do? You would  create 5 accounts (each  person has their
own  login) and  then put  all 5  people into  a group  that have  group
permissions to  edit the document  and then  set the group  ownership on
that file to that group and make the file group writeable.

The default mode  of operation for Fossil works in  similar fashion. You
just need  to put the  Fossil repository file  into a directory  that is
writeable by the group and has  permissions on the file that permit them
to read and write to it.  Perhaps the repository is located in:

/var/fossils/project.fossil

When they clone they would clone using their own account.

fossil clone ssh://username@host//var/fossils/project.fossil ~/fossils/project.fossil

Using  public  key  authentication  does  not  change  this  arrangement
significantly but can allow more flexibility.

Keep in mind that this default  mode of operation assumes that all users
are fully enabled users because they  all have complete control over the
Fossil  repository. This  simple setup  also has  the least  maintenance
overhead.


Now,  perhaps you  have people  who are  not very  experienced in  using
shells and  SSH and you're  concerned about  the security of  the system
being compromised?  And you want to  limit their access to  simply using
the Fossil command and disallow interactive shell. Well, that's where it
gets slightly more  complicated and you have a bunch  of other decisions
to make. The first and most simple  thing you can do is disable password
authentication  for those  users and  then  require SSH  keys. Then  use
ForceCommand to force  the SSH key to always invoke  the Fossil command.
How you go about  doing this depends on whether or  not you think you'll
have just 1 Fossil repository in the group, or multiple.

If you have  one, the ForceCommand could contain the  name of the Fossil
repository right in it.  For example:

command="fossil test-http /path/to/fossils/repository.fossil"

If you  have multiple, then you  might want to  instead use a path  to a
directory and  then Fossil will  "serve" any of those  repositories. For
example:

command="fossil test-http /path/to/fossils"

The latter mechanism allows any of  the Fossil repositories to be served
(assuming you have multiple).

The above  examples are  for putting the  ForceCommand directly  in each
user's  $HOME/.ssh/authorized_keys, but  if you  want to  centralize the
control and make it impossible for  users to disable, you would then put
them in Match blocks for the User in /etc/ssh/sshd_config.


If you're brave  (or determined) you can get more  fancy with Fossil and
do as you  suggest. Create a "fossil"  user that owns the  file and then
control access  to that by using  ForceCommand and SSH keys  and you can
even take  advantage of the Fossil  RBAC system. This is  similar to how
many GitHub users are accustomed to doing things (e.g. the SSH transport
doesn't use their own name at all, but a very generic git@github.com).

Some of what you can do in this regard is documented here:

https://fossil-scm.org/home/doc/trunk/www/server/any/http-over-ssh.md

So it really comes down to how you want to provide the access.

Feel free to ask questions for clarifications.

Andy