Kallithea issues archive

What version/revision of Kallithea are you using?

In https://server/_admin/settings/visual , what do you have as SSH Clone URL?

‌

Ok, after reading again and understanding the problem and the question:

No, that is not a bug. When the user log in, there will be be a .ssh/authorized_key entry that points to the ssh wrapper that will do access control and add the repo root.

Does that not work for you?

Thanks for your prompt reply.

1. In https://server/_admin/settings/visual, I need to modify the SSH Clone URL template to ssh://{system_user}@{hostname}/kallithea_root/{repo}. I don’t know if there’s a variable for the root. (thanks for the hint, I didn’t know it could be set manually.)
2. I don’t fully understand your second comment. The entry for the user in question has command="/home/system_user/.local/bin/kallithea-cli ssh-serve -c /home/system_user/.kallithea/config.ini 2 1" as part of the entry. But I don’t see how that knows where the repo root is. Can you please elaborate?

‌

The logic flow is that sshd will launch kallithea-cli with the .ini which points to the database which has the repo root which then is used in relevant places. The repo root is a server installation/implementation detail that generally isn’t leaked.

If you have to edit the template to include your repo root then you are bypassing the authorized_keys entry installed by Kallithea … and if Kallithea isn’t invoked, ssh and hg/git can of course not do anything. You will have to debug your ssh setup to figure out why sshd doesn’t match the authorized_keys entry. But if you figure out what is causing it, perhaps Kallithea can help avoid that situtation somehow - that depends on what the problem really is.

Thanks for the explanation; that clears things up a lot. It turns out to be a silly-ish problem on my side---I had my normal ~/.ssh/authorized_keys handling regular ssh connections and also another kallithea authorized_keys for hg's ssh. Now I can’t tell them apart if the client is registered in both. But that has nothing to do with kallithea per se. I’ll investigate a workaround. Thanks.

Can you say more about “another kallithea authorized_keys”? Is it possible for ssh to have multiple authorized_keys?

Can you suggest how documentation / system could be improved so it would have helped you?

First off, some disclaimer: I’m not a professional sysadmin. I’m just setting my server for my own convenience. So it’s very likely that I do things wrong or introduce security risks.

In /etc/ssh/sshd_config (or similar depending on the system), a thing can be set up is AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 (a list of files can be given). In my case, I have the default .ssh/authorized_keys and a one for kallithea /home/system_user/kallithea/authorized_keys. They are read in the order by sshd. I can have the same key in both with different options, but the first one will always shadow the second. If I have the default first, then hg's ssh won’t invoke kallithea-cli which was the problem I had; if I have the kallithea one first, then I can’t do normal ssh logins, unless with very complex arguments to ssh.

I’m mostly happy with the level of details and the amount of information given in the documentation and appreciate the effort the authors have put in, as I know myself how difficult it is to maintain good documentation. Of course it would have helped me if I could find any information about how the code is structured so I know where to look for relevant code, but that’s quite a different story and is not so common in open-source projects in general (one example is https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/#the-ghc-commentary).

‌

Nice trick about multiple AuthorizedKeysFile - I didn’t know about that. We should perhaps mention that in the documentation.

I would indeed expect that for each ssh key, it will always pick the same access (with command=kallithea-cli or shell) without fallback to the other. But the user can have different ssh keys on the client side and thus hit different entries.

I don’t see how multiple keys would work. As the first key is attempted, the server will use it. If it fails, the second key won’t be attempted. It doesn’t behave any different than having only one ssh key. Or am I missing anything?

On the client side, it is possible to have many keys. If using another key than the default (usually ~/.ssh/id_rsa ), it can be specified with ssh -i .... A user that also is admin could thus have one key that gives Kallithea repo access, and another one that gives a command line.

But best practice is to not ssh to the Kallithea system user, but let each admin ssh as themselves and sudo to the Kallithea system user (or root).