Hello, After giving a little though to handling shared SSH accounts, it might be as simple as the following change:
https://www.fossil-scm.org/index.html/info/7a10b79a2c Basically, if the specified SSH command already has an '@' in it, don't use the username@host found in the URL, but use the username@ to provide Fossil authentication token once the SSH connection is established: local$ fossil clone -c 'ssh -e none -T guest@remote' ssh://amb@remote//tmp/test.fossil /tmp/test.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http /tmp/test.fossil guest@remote's password: Round-trips: 2 Artifacts sent: 0 received: 1 ssh -e none -T guest@remote fossil http /tmp/test.fossil guest@remote's password: Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 547 bytes sent, 1158 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 125ab947e5a9aff39560a0d60dddccac37f575fa admin-user: amb (password is "85cf0e") Then, after opening and making a change: local$ fossil commit -m test Autosync: ssh://amb:*@remote//tmp/test.fossil Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http /tmp/test.fossil guest@remote's password: Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 349 bytes sent, 286 bytes received New_Version: 6d982f5dfbfcf4d283bbb073fc04dfd7c50f5b32 Autosync: ssh://amb:*@remote//tmp/test.fossil Round-trips: 1 Artifacts sent: 2 received: 0 ssh -e none -T guest@remote fossil http /tmp/test.fossil guest@remote's password: Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 542 bytes sent, 338 bytes received The info stored with the commit on the remote host shows that the changes were made by amb (not guest) coming from the local host's IP. So, it uses the SSH connection established by the guest@remote account, but still relies on the fossil credentials to be able to control commit. Of course this probably really only makes sense when using forced command SSH keys, but it does seem like a pretty direct way to be able to support a shared SSH account configuration. Thoughts? Thanks, Andy -- TAI64 timestamp: 4000000051e61a05 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
