Access repos through ssh://user@host/repo

Is it possible to access a repo through a URL of the form ssh://user@host/repo (which becomes just ssh://host/repo if the user name of the machine is the same)?

The reason I’m asking is because I want my users to have no SSH setup to do before accessing the repos. With my current setup, any user in my company can ssh into the rhodecode server without typing a password or setup a key pair. I am not 100% sures how it works, but the SSH clients use the GSSAPI auth method and the authentication works out of the box.

Today if I try to do this, the authentication works, but the repository is not found:

hg clone ssh://me@rhodecode.mycompany.com/myrepo
remote: Using SSH protocol version 2
remote: Using username "me".
remote: Attempting GSSAPI authentication
remote: Access granted
remote: Opening session as main channel
remote: Opened main channel
remote: Started a shell/command
remote: abort: repository myrepo not found!

(I removed irrelevant output lines)

Is there any way I can leverage this authentication method? I’m only interested in Mercurial.

Hi,

Yes the ssh protocol is supported, please check out docs on how to setup SSH access to repositories.

Best,

I’m afraid there is a misunderstanding. Sorry if my question was unclear, but I am asking about a specific configuration of the SSH access.

Basically, the default SSH URL is ssh://{sys_user}@{hostname}/{repo} and I would like to use ssh://{user}@{hostname}/{repo} instead, for the reasons I explained above.

As far as I understand, {sys_user} is the user that runs the rhodecode process, and it forces the users to upload/generate a key pair. My question is whether it is possible to use the name of a user here ({user}), to leverage the SSH authentication that is already setup.

Hi,

Sorry about that confusion !

So the way it works is that a special config for SSH is generated for that sys_user. This basically executes a SSH command for that sys_users, and based on an associated particular ssh key permissions etc are verified.

What you described could be possible, if such configuration file is created for each user account on your machine, following same principles the whole thing should just work.

You’d need to manually setup, and adjust those SSH configurations for each user, and make sure the still generated configuration for sys_users isn’t included in your sshd configuration so it wont work for the sys_users.

Hope this is clear now.

1 Like

Thanks, this gives me some hints for where to look. I’ll give a feedback if I am able to make it work.

I looked into this, and I don’t see a technical solution. I’ll write down my findings, in case it can help others.

RhodeCode expects the SSH connection to use the Public-Key authentication method. This works only for authenticating the user who runs the rhodecode process (sys_user). When the authentication succeeds, how does RhodeCode knows what user is trying to access a repo? And when does the logic to check the permission takes place? The answer is that the Public-Key authentication uses the file ~/.ssh/authorized_keys_rhodecode, that contains one line for each key imported/generated from the Account / SSH Keys page. Note that this file does not exist until a key is imported/generated by any user. And this authorized_keys file actually has the ability to rewrite the command that the hg client requested. This is the command= part in each line. The command is in fact a SSH wrapper shipped with RhodeCode, and the name of the user is simply set as an argument to this wrapper.

So, what I originally wanted is to leverage my existing GSSAPI authentication method (my understanding is that it’s using Kerberos under the hood). But this approach seems incompatible with the existing system, because GSSAPI does not use authorized_keys at all. I cannot find a way to rewrite the SSH command like the command= part does, and even if I could I would not have the right permissions to call into RhodeCode.

If there is a way to make my idea work, I have no idea what technical solution it could be based on. Too bad for me!