Issue #1660 wontfix

ssh problems with multiple accounts

created an issue

I have two accounts on bitbucket. One is my own personal one for my own open source stuff. The second is for work where I then have access to a paid for repository.

I had to associate a SSH rsa key with one account and dss key with the other (you won't allow the same SSH key for different accounts). Unfortunately bitbucket gets confused since it appears to guess my user based on what ssh tried to negotiate since the username is always 'hg' but SSH seems to pick keys in a random order.

Please can you let me specify my account name in the SSH URL instead of 'hg' which will make all these kind of issues go away.

If you won't do that then at least please put who you think I am in error messages. Below is an example of an error I am currently getting, but I can't tell who bitbucket thinks I am - it just says "You're":

{{{ $ hg push ssh:// pushing to ssh:// searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files remote: error: pretxnchangegroup.bb_perm hook failed: You're not allowed to write to this repository. remote: transaction abort! remote: rollback completed remote: abort: You're not allowed to write to this repository. abort: unexpected response: empty string }}}

Comments (19)

  1. rogerb_aviga
    • changed status to new

    Nope. I pretty much have given up on using ssh with bitbucket because most of the time it fails. Some of my checkouts still have ssh url as the default so I keep being reminded. Or in other words, it failed twice today for me already.

    For example doing this right now I get:

    $ time hg pull
    remote: conq: repository access denied.
    abort: no suitable response from remote hg!
    real	0m32.117s
    user	0m0.040s
    sys	0m0.000s

    Both my ssh key identities are currently loaded in the agent.

  2. Jesper Nøhr
    • changed status to open

    The first issue (the 30 second delay), is as of now, fixed.

    As for the second issue, where your agent picks a key in a random order, what you're seeing is expected behavior, isn't it? It's correct for us to refuse your other user to write to this repository.

    You could probably get around it with some hacking of hgrc, specifying something like this:

    ssh = ssh -i ~/.ssh/the_correct_key

    You can stick that in your repos' hgrc, and it should work consistently.

  3. Brodie Rao

    For whatever reason, it seems ssh-agent takes priority over ssh -i. I'm not sure there's anything we can do on Bitbucket's end.

    If you don't mind bypassing ssh-agent for your secondary Bitbucket accounts, you can try this:

    ssh = ssh -i ~/.ssh/the_correct_key -o IdentitiesOnly=yes
  4. rogerb_aviga

    It isn't resolved. You've just forced people to go through an incredible amount of legwork.

    The underlying problem is that you specify the ssh user as 'hg'. If you allowed my actual user name then you can behave as real ssh servers do which is to reject all keys that do not match the specified user, with the client sending all keys it knows about.

    Fixing this would also make life easier for you. Right now when an incoming ssh connection comes in you have to search your entire userbase for a match, rather than just the keys associated with the supplied username.

    And if I was a bad guy, I would very much appreciate the current approach. I can use any random key and you'll turn that into a username for me.

  5. Jesper Nøhr

    Not entirely sure I agree with that. You'd have to forge a valid 1024 bit RSA/DSS key, and you'd get the username.

    We can't have 90.000 users on our system either, so 'hg' is the user we're using. It's a bug in ssh-agent, picking the wrong user here.

  6. rogerb_aviga

    The ssh protocol does not work that way. What happens is that the server says it accepts public key (and possibly password etc) and the ssh client presents each of the keys it has one by one and then when they are exhausted moves onto the other mechanisms until the server accepts something.

    There is no bug in ssh agent or the client side. By definition it does not know which keys the server will accept so it has to try them all, or you have to go through configuration gymnastics to tell it to only offer one.

    I hadn't expected you to create thousands of actual unix users, but rather lightly modify your ssh daemon (which presumably you have done already) so that if the user is 'hg' then you search through 90,000 possible matching keys and if it is something else then you only look for the keys stored against the named username. This will solve the problem nicely.

    You don't need to forge a key. You use Google to find which people have their keys available either lightly or not password protected, and then mechanisms like your current one make it easy to login without having to guess the username.

  7. Jesper Nøhr

    I understand how SSH works; the bug lies in that ssh-agent doesn't respect you specifying the -i keyfile option to your ssh command, it instead gladly offers a random key. We had another user test this out for us.

    We're using a stock OpenSSH server with no modifications. This allows us to stay on top of updates and security patches without having to keep a set of patches around we have to keep up to date.

    As for finding people's keys, you'd only need to deduce their username (from their email address, or username on advertised social networks), and you'd be in anyway. Placing your private key, w/ no password, in public, is just not safe.

  8. rogerb_aviga

    We are talking at cross purposes here. Sure you can do lots of gymnastics with ssh configurations in order to convince it to send the right key first, but that is a significant hassle. Given that Mercurial encourages lots of single purpose repositories and making frequent clones as branches, this is a lot of extra work to have to do.

    Its your site and you can make people like me jump through whatever hoops you want, but I certainly do not enjoy having to make these reconfigurations on every single working copy. If there was a way of specifying the user then they would not be necessary.

  9. peak
    • changed status to open

    I have followed the exchange above as I have been having the same kind of problem. It seems to me the issue is most definitely unresolved.

    In particular, I have tried specifying "ssh = ssh -i /.ssh/id_rsa" but bitbucket says:

    remote: conq: repository access denied abort: no suitable response from remote hg!

    I've also tried adding the suggested -o option but that makes no difference.

    The repository I am trying to access requires ssh (because of the .hgsub file), so there does not seem to be a workaround.

    Thank you.

  10. Anonymous

    Had the same problem with multiple accounts. Modifying the hgrc file with the -o option did solve the issue:

    ssh = ssh -i ~/.ssh/the_correct_key -o IdentitiesOnly=yes
  11. Jesper Nøhr

    I'm gonna close this one. Modifying OpenSSH is not an option for us, and we'll stick with the "hg" username for everyone.

    I realize this is cumbersome for people who use a combination of multiple keys and ssh-agent, but unfortunately there's no easy fix for those people, or for us.

  12. Mark Reed

    I realize this is cumbersome for people who use a combination of multiple keys and ssh-agent

    as opposed to . . . ? what's the alternative?

  13. Gloops Redmine
    ssh = ssh -i ~/.ssh/the_correct_key -o IdentitiesOnly=yes

    Is there a similar fix/workaround for Git repos like the above for Hg's hgrc? I'm also having ssh issues for multiple ssh accounts trying to tap a Git repo hosted by Bitbucket?

  14. Brendon Rapp

    That's almost correct, except the User directives are pointless, since the real usernames getting used are "git" or "hg".

    And, if you instead put "git" or "hg" in as the User, you take away the need to do "". You'll no longer need the "git@" part.

    Enter in something like:

     User git
     IdentityFile ~/.ssh/Key.MyName
     User git
     IdentityFile ~/.ssh/Key.WorkName

    ... then now your git clone command would be: git clone

    No more "git@" or "hg@", the ssh config now does that for you.

    In fact, you don't need to make the Host appears as a full DNS address. You can make your Host entries have names like "work-bb" and "my-bb" and make your URLs be like: git clone my-bb:MyName/somerepo.git

  15. Pat Dunlavey

    I can ssh to bitbucket using my ssh alias '' (set up in ~/.ssh/configure)

    pat$ ssh -T conq: logged in as [my_account_name]. You can use git or hg to connect to Bitbucket. Shell access is disabled.

    I have my git remote set up to use that alias (which has 'User git', so no need for git@)

    pat$ git remote -v origin[my_account_name]/[my_repo_name].git (fetch) origin[my_account_name]/[my_repo_name].git (push)

    But when git tries to connect, ssh-agent seems to have forgotten about the alias

    pat$ git fetch --all Fetching origin ssh: Could not resolve hostname nodename nor servname provided, or not known fatal: The remote end hung up unexpectedly error: Could not fetch origin

    Any suggestions very welcome!!

  16. Log in to comment