I'm pretty sure that when using ssh://, since you have full read/write access to the db file (.fossil), fossil authentification for clone/sync/push/pull is bypassed completely, so it doesn't matter what password your user have for the repository.

So I don't know why you get this "'Error: not authorized to clone'" error, but it's certainly not because of any fossil related password.

When you ssh with user_x, you have read/write access to the ".fossil" file and directory where it reside ?

Can you show us your complete fossil clone ... command ?

Yes. OP is misattributing the cause of his symptom. Unfortunately, with all the other complications he's introduced, it's hard to say exactly what the actual cause is.

There are no complications

There is a user at the ssh server called, say x with password wibble. There is a user in the fossil repo also called x with password ftang.

performing fossil clone ssh://x@someaddress/somerepo.fossil

asks for a password. The password is asked for by fossil, if given 'wibble' it will log into ssh successfully, but then reports 'Error: not authorized to clone'

If I ssh in as the user, I can happily clone via the file but I get 'not authorised to read'.

X is the setup user.

The password is asked for by fossil

Fossil should not ask for a password in this case, fossil authentication is bypassed when cloning/syncing via ssh.

When fossil ask for a password and it fail (when using http://), it looks like:

password for user_x: 
remember password (Y/n)? n
Round-trips: 2   Artifacts sent: 0  received: 375
Error: login failed 
Round-trips: 2   Artifacts sent: 0  received: 375
Clone done, wire bytes sent: 627  received: 5306888  ip: xx.xx.xx.xx
server returned an error - clone aborted

There are no complications

In your original posting you brought up client-side certificates and SSH command overrides. Now you give an example without them, removing these complications. It may be your personal requirement to add these complications that is causing the problem, because your simplified example doesn't exhibit the reported symptom here.

The password is asked for by fossil,

And there you go astray. It is sshd on the remote side asking for the password via the local ssh command instance, not Fossil. It is always and only asking for your remote user's password, since you haven't set up SSH keys or another way for the local SSH program to log into the remote system.

Study this lightly-expurgated and annotated transcript, done with tip-of-trunk Fossil:

1. Create remote repo:

   $ ssh fossil-server 'fossil init tmp/y.fossil'
   project-id: cdeb3aebd2744634ca75fc70f15c659a25949b1a
   server-id:  3241a4bb392507e0d206f662a08163243cba3574
   admin-user: x (initial password is "BQm3THiKva")
   

   Notice that we're using the remotely-generated password, not my actual local user password, so they differ as you claim is required to show the symptom. I've replaced my actual local user names with "x" to match your example.

2. Clone remote repo to local machine:

   $ fossil clone ssh://$USER@fossil-server/tmp/y.fossil ~/tmp/y.fossil
   Round-trips: 2   Artifacts sent: 0  received: 4
   Clone done, wire bytes sent: 578  received: 1160  ip: 10.0.10.110 (fossil)
   ...blah blah blah...
   admin-user: x (password is "5uqVJirQWt")
   

If the same two-command sequence fails for you, it is because of some difference in the environment, not because Fossil is confusing your local and remote user credentials.

And before you go on arguing with me, realize that I wrote the document I linked to from my prior reply. I wrote it based on examination of the source code, plus years of Fossil use backing that study with experience. I won't claim to be infallible, but you're the new one here. Maybe consider that those of us with more experience do actually sometimes know what we're talking about.

I get 'not authorised to read'.

So your remote file permissions are probably wrong, as predicted by Monsieur Gagnon.

Also, note that the string "not authorised to read" doesn't even appear in the Fossil source code. It was the British spelling that tipped me off to check: Fossil would use the American spelling, "authorized," but that version of the string isn't present, either. Some other piece of software is issuing this message, not Fossil. My guess is sshd again, running under an en_GB type locale.

X is the setup user.

Doesn't matter. Everyone is the setup user under this regime.

Click the "blame" button up at the top of that page and note who changed the "sxy" line most recently. Could it be that I know what I'm talking about here?

Incidentally, that final point does show that your mission to replace Fossil's HTTP-based permission system with SSH is likely doomed. If everyone can clone from and push to a given remote repo over SSH, they're all Setup users, so what have you achieved?

One of the Andys here has posted a few times about a method to tunnel HTTP over SSH without using the permission-free test-http interface, but then I think you're back to your original problem with not liking how login groups are implemented.

Warren,

When you did the ssh login, was it using passwords (I don't notice the password prompt in your output).

I'm not trying to replace it - I have a single repo that I wanted to clone via ssh rather than serve (it's not a company one, rather one of mine) and came across the issue when trying.

I'm not claiming fossil was in error, merely trying to provide as much info as possible to see what is causing it (that is, what I might be doing to provoke it).

Could it be the journal creation permissions?

No, because I have SSH keys set up between those two servers.

But just to placate you, I've gone and broken that link, and it still operates as I claim.

(Incidentally, I set PasswordAuthentication to "no" in sshd_config on my systems wherever practical, so that SSH keys are the only way to log in. I had to temporarily revert that security measure as well.)

Yes, I have done it via a tunnel, the issue was using the ssh built-into fossil (I understand the file ownership issues and checked those). All the answers should give me pointers to what is the issue at this end.

Apologies if my questions sounded brisk.

Yes, it could be. You need write access to the repo's directory as well as to the repo file itself, because the remote Fossil instance (run via ssh) does need permission to write those on the remote system.

It wasn't the "briskness" of your reply, but your apparent assurance that the docs were wrong when they told you the remote Fossil repo's user capability system isn't consulted at all when using anything other than an http[s]:// URL.

I added that section to the docs specifically because this is surprising. You were expected to go "Oh, really? That's strange. There goes hypothesis #1", not double down on your position.

I suspect the 'Error: not authorized to clone' may have mislead me there.

There wasn't really a goal as such - while setting up the fossil served repos I realised I had a private one I did not wish to share, so thought I'd clone it via ssh from a personal machine. I managed to do so eventually via the usual -L port:...port: stuff but wondered why the ssh mode caused problems. It's really just interest and an itch to scratch now - wondering what's different here (ssh version?).

I tried the -vv command within fossil clone -c (along with other ssh commands) but always got the core dump and 'unauthorised setting' from fossil (in db.c).

Actually.. thinking about that, that occurs before the ssh attempt so what db is the 'unauthorised setting' reporting on? With the 'not authorized to clone' error from fossil plus the sshfs failure I'm wondering if those are related to the local copy created before the actual clone (when it fails, one is left behind).

My local linux username is (say) rjl, the user within the fossil repo is rjl, the ssh user is rjl (distantly). Access using ssh is via passwords, the passwords differ between session and fossil repo. On the assumption that others have done that successfully, there must be some combination here that is problematic (ssh version?).

I can ssh into the remote site using a password and access the repo with no issues, but using fossil clone ssh I cannot. I also tried via an sshfs mount and that failed party through the clone (at the end from what I could see) which made me wonder about my journal / sqlite log file permissions (per https://fossil-scm.org/forum/forumpost/ba2f639a6afef2e6?t=h where Stephen fixed the import command).

I'll have to retest the sshfs one to check what failed, in fact, I think I'll have to tabulate it all or I'll never sleep again!

I believe I've fixed the "unauthorized setting" complaint on trunk. Giving -vvv with it appears to work here with a test clone.

Beware that this choice is stored in the repo as a persistent setting, so until you override the ssh-command setting, every sync operation will use the same flags, which is annoying if you gave it -vvv.

EDIT: By the way, I would very much not recommend using sshfs with Fossil repositories, or indeed any other type of SQLite DB.

Thanks to both for the SSHFS warnings.