Hi Leo and everybody else.

I am not an avid poster online, (and English is not my native language) so please bear with me.

I have also had a problem cloning over an ssh connection.

Each time I've got the response:

[...]
Error: not authorized to clone
[...]
fossil: server returned an error - clone aborted

I am 99.99% certain that I connected with the right username and password of a user with clone rights, as I am able to clone via http with the same user.

On Mon, 06 Feb 2012 12:05:47 +0100, Leo Razoumov <slonik...@gmail.com> wrote:
However, when I enable "Private" flag on user "nobody" everything
works as expected. It makes me think that somehow my clone session is
always conducted as a "nobody" on remote server.

My problem also disappeared when I allowed clone-rights to 'Nobody'.
This suggest that Leo Razoumov's observations are valid: ssh-connections only infer the 'nobody' rights.

This is not the expected behavior, i think.
I would expect, using a ssh-connection, that I might have the 'local-/super-user' rights, or at least the rights set for the username (eg. clone + some others).

Have I (unwittingly) messed something up?

I think this might be related to another issue with the cli-design.
It is not obvious how to specify a username to clone with that is different from the username with which to make the ssh-connection.
(I guess you could specify the username in 'fossil setting ssh-command'.)

This is a design error, not at least because of the password requests.
E.g. 2 password requests when only one username is given to the fossil clone command. The only difference is that the second request specifies the (remote) domain (which means this is the ssh password request).

Kind regards,
Sverre
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to