clone via ssh same user different passwords
(1.2) By Robert Ladyman (RoJaLa) on 2021-09-01 09:45:07 edited from 1.1 [source]
I am unable to use fossil clone ssh://user_x@
where I have an ssh account with the name user_x and the same name in the fossil repo BUT they do not have the same password nor the same user name on the local system
(so, local user_z, ssh user_x, repo user_x)
The fossil clone command doesn't seem to permit this possibility
If I use the ssh password (which is needed for access) the fossil command assumes that password as well and returns 'Error: not authorized to clone'
If I use the fossil repo password I (obviously) get 'Permission denied...' from ssh itself.
I note that once can pass an ssl-identity but that is not this case as the user-names are the same (I looked at [forum:53a0fda986ca38d94af181851d92b8b2571e021470839682b0f0ce019c4faedf])
To pre-empt: no, I cannot use certificate access in this case. No I cannot make the password the same (that would not help, I have other fossil repos with different passwords).
If I try
--ssh-command 'ssh -e none -T -l user_x' ssh://user_x@
core dumps with ' unauthorized change to protected setting "ssh-command" '
As a side-note, files named reponame.fossil and reponame.fossil-journal get created locally anyway.
Edit: looking at the code in db.c, I suspect that the 'unauthorized change' is a result of fossil minsreading the failure of the clone and trying to read the (failed) local reponame.fossil.
(2) By Martin Gagnon (mgagnon) on 2021-09-01 11:38:40 in reply to 1.2 [link] [source]
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 ?
(3) By Warren Young (wyoung) on 2021-09-01 12:33:46 in reply to 2 [link] [source]
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.
(4) By Robert Ladyman (RoJaLa) on 2021-09-01 14:37:11 in reply to 3 [link] [source]
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.
(5) By Martin Gagnon (mgagnon) on 2021-09-01 15:02:25 in reply to 4 [link] [source]
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
(6.2) By Warren Young (wyoung) on 2021-09-01 15:40:39 edited from 6.1 in reply to 4 [link] [source]
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:
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.
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?
(7.1) By Warren Young (wyoung) on 2021-09-01 15:43:10 edited from 7.0 in reply to 6.1 [link] [source]
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.
(8) By Robert Ladyman (RoJaLa) on 2021-09-01 15:43:25 in reply to 7.0 [link] [source]
When you did the ssh login, was it using passwords (I don't notice the password prompt in your output).
(9) By Robert Ladyman (RoJaLa) on 2021-09-01 15:44:56 in reply to 7.1 [link] [source]
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.
(10) By Robert Ladyman (RoJaLa) on 2021-09-01 15:46:26 in reply to 6.2 [link] [source]
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?
(11) By Warren Young (wyoung) on 2021-09-01 15:48:32 in reply to 8 [link] [source]
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.)
(12) By Robert Ladyman (RoJaLa) on 2021-09-01 15:49:01 in reply to 7.0 [link] [source]
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.
(13) By Warren Young (wyoung) on 2021-09-01 15:49:22 in reply to 10 [link] [source]
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.
(14) By Warren Young (wyoung) on 2021-09-01 15:51:53 in reply to 12 [link] [source]
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
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.
(15) By Robert Ladyman (RoJaLa) on 2021-09-01 15:54:35 in reply to 14 [link] [source]
I suspect the 'Error: not authorized to clone' may have mislead me there.
(16) By Andy Bradford (andybradford) on 2021-09-01 20:08:30 in reply to 7.1 [link] [source]
> 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 Minor clarification. The "tunnel" here is nothing different than what Fossil already implements---it's nothing special. Fossil's SSH integration is simply forking an SSH process and that process will prompt for a password if SSH determines it needs a password. It then runs a remote command of "fossil test-http" by default over the "tunnel" that SSH creates. By taking advantage of ForceCommand, the SSH server can instead require clients to run "fossil http" over the "tunnel" instead of "fossil test-http". However, operating in this way does also mean that Fossil permissions and capabilities will be honored. What exactly is the goal? Andy
(17) By Andy Bradford (andybradford) on 2021-09-01 20:11:00 in reply to 4 [link] [source]
> 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' In this case, Fossil is not prompting for a password, your ssh binary is. Have you checked the permissions on the repository and the directory in which the repository lives to make sure that x can write? Thanks, Andy
(18) By Andy Bradford (andybradford) on 2021-09-01 20:20:57 in reply to 12 [link] [source]
> All the answers should give me pointers to what is the issue at this end. You can change your ssh-command to include -vvv so we can see what the server is executing. You can also run fossil with --sshtrace: fossil clone -c "ssh -e none -T -vvv" --sshtrace ssh://remote//repository.fossil N.B. there appears to be a bug here... I tried to use -c and it aborts: fossil clone -c "ssh -e none -T -vvv" --sshtrace ssh://localhost//... /***** panic on 504 *****/ unauthorized change to protected setting "ssh-command" Abort trap (core dumped) Andy
(19) By Robert Ladyman (RoJaLa) on 2021-09-02 07:14:40 in reply to 17 [link] [source]
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!
(20.1) By Warren Young (wyoung) on 2021-09-02 08:58:28 edited from 20.0 in reply to 19 [link] [source]
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
EDIT: By the way, I would very much not recommend using sshfs with Fossil repositories, or indeed any other type of SQLite DB.
(21) By Andy Bradford (andybradford) on 2021-09-02 13:31:35 in reply to 19 [link] [source]
> Actually.. thinking about that, that occurs before the ssh attempt so > what db is the 'unauthorised setting' reporting on? When you use the -c option for clone, it stores whatever command you give it as a persistent comand to run everytime you sync with the remote source. This is no different than Fossil's ability to store your username/password for a remote. Fossil has worked this way for years, so what you're seeing is just a bug (not sure when it was introduced). At any rate, you don't have to rebuild Fossil or pass in the -vvv option to Fossil's ssh-command to get additional debug out of SSH. You can also modify your ~/.ssh/config and enable it there. For example: Host remotehost LogLevel DEBUG3 Then when you clone you'll get debug output from SSH. When you do run this, please provide proper output as it is seen on the terminal. If you want to mask username and hostname information that's fine, but do so in a way that the rest of the text is left in tact. As for your comment that people must be using SSH without problems, this is true. I use it pretty exclusively for all of my repositories. Stay away from SSHFS, it will just confuse matters and isn't reliable for Fossil use. Andy
(22) By Robert Ladyman (RoJaLa) on 2021-09-02 14:00:06 in reply to 21 [link] [source]
Thanks to both for the SSHFS warnings.