Someone has already registered that SSH key.

Issue #5154 closed
Boris Cosic
created an issue

I have a work and personal accounts for which I prefer to use one public key for all my SSH access. I have registered a new username and tried to import my public key I use for work account (different username) and got an error "Someone has already registered that SSH key.". Is there a way around this because I won't be using the service if I need a different private/public for every username I work under.


Official response

  • Erik van Zijst

    The reason this doesn't work is because when you use SSH, we use your public key to identify the Bitbucket account. The consequence of this is that the public must be unique throughout the site.

    This is distinctly different to, say, https. When cloning over https, you provide your (unique) username and so your password does not need to be unique.

    With SSH however, no username is provided and so the key must uniquely identify an account.

Comments (107)

  1. Marcus Bertrand staff

    Boris, sorry to day this is the case. Many people prefer to either use the same user for all activities on the site while others choose to keep a second work/personal account. In the latter, they usually have work keys and personal keys.

  2. Jed Tiotuico

    Please please reconsider. I have my work email registered to my Bitbucket account and I have my own personal side-projects that I want to attach to my personal email account.

  3. Roger Gujord

    Hey, why not go all the way and do the same for passwords? ;-) Someone has already registered that password. Same thing but collisions should not occur with ssh-keys... but take a look at recent events for BitCoin on Android caused by a bad random number generator. Please reconsider your won't fix. Thanks.

  4. Tom Worster

    How does it benefit Bitbucket, me or anyone else that I have to create more PK pairs in order to have more than one persona in Bitbucket?

    This strikes me as a well intended security check that actually ended up being a bad idea. By analogy, strict password length and "randomness" policy encourages users to use unrememberable passwords that they then write down and pin on the wall. Making me create and manage more keys isn't going to improve Bitbucket or my security. On the contrary, it makes it easier for me to make careless mistakes.

    So, imo, it is a bug. Please fix it.

  5. bcoder

    -1 for won't fix.

    Which user is "already using that key"? It's obviously some other account created by me in the past. At the very least, I should be able to override the other use.

  6. bryan_murphy

    I also have been bitten by this restriction. I wanted one linux account with a single ssh key to be able to access different bitbucket repos owned by two users which meant I needed to register the same public key for two users and of course it failed for the second user. Makes no sense to me.

    However, I found a workaround via a VERY neat feature in ssh using the config file. This link (simplify-your-life-with-an-ssh-config-file) explains it but effectively you create aliases for the host.

    Eg if you have this in your ~/.ssh/config

    Host bitbucket-alt
        User git
        IdentityFile ~/.ssh/id_rsa2

    Now, if you create another ssh key using ssh-keygen (I named it id_rsa2 ) and then add its public key text to the second user's bitbucket keys you can control which user's repo gets used by the hostname in the repo URL

    eg to access the second user's repo:

    git clone git@bitbucket-alt:user2/somerepo.git

    and you can continue to use for accessing repos associated with the first user's bitbucket account.

    So a big +1 for ssh and -1 for bitbucket

  7. Erik van Zijst

    The reason this doesn't work is because when you use SSH, we use your public key to identify the Bitbucket account. The consequence of this is that the public must be unique throughout the site.

    This is distinctly different to, say, https. When cloning over https, you provide your (unique) username and so your password does not need to be unique.

    With SSH however, no username is provided and so the key must uniquely identify an account.

  8. Arrd Ahlgren

    This is a ridiculous restriction. Collisions, though mathematically rare, are not impossible. Firstly, it shouldn't matter if another user has uploaded the same key (assuming this is an actual collision, will they brute force all repositories to find access to one?) - secondly, you are leaking information about your system by telling users that a collision has occurred.

    As said above, please listen to your users. Fix this.

  9. Arrd Ahlgren

    I understand the restriction with using a single user account for ssh access across the entirety of the bit bucket system - perhaps this could be investigated? It's crazy feature creep, but perhaps it would make sense to expose a git-$username account for this purpose instead?

    Generally, this restriction is not a problem with git, as generally only a handful of users have access to the server. For products such as github and bitbucket, some tweaking may be in order.

    Thanks for your time

  10. Dean Mraz

    I agree with everyone here this should be considered a bug. I too use the same computer for work and personal projects but have different accounts. I should only have to auth the computer with one ssh key and not have to manage two ssh keys for a single computer.

    -1 for wont fix

  11. Florin Iacob

    -1 for wont fix
    +1 for +1 for -1

    this is absurd, really ... why bitbucket would provide an interface for trying public keys to see if they are registered ?

    if not a bug at the conceptual level, than, by all means, an logical/architectural mistake it is

  12. ikdc

    This is a huge blocker. I registered my SSH key with a group account that I no longer have access to, nor can I contact those who do. Thus, I can't register my SSH key at all now, and I can't unregister it from the group account. I should be able to override the previous registration by providing a cryptographic proof that I possess the private key.

  13. Greg Barker

    @ichung it's just an SSH key, generate a new one and use that instead

    @prathiklive & @jasper Please don't reply with useless comments like "-1 for wontfix". It adds nothing but annoying notifications to everybody following this ticket. Just vote on it instead. Or even better, read the reply by @ut-jonathan right above yours and maybe contribute something meaningful to the conversation.

  14. Jaimil Prajapati

    I completely agree. This is ridiculous! I have 2 accounts - one more Personal and one for Company. I'd like to keep my repositories different as currently I cannot receive notifications on different e-mail addresses based on Repos. For ex. I don't want e-mails for changes on Company repos to be sent to my Personal account or vice-versa.

    Please fix this issue! This is a bug!

  15. Prashant Kumar

    Till the time they keep it as 'wont fix', you can use https instead of ssh for clone and push/pull operations. Works fair enough for me (though putting in the password everytime is a pain in the ass)

  16. Evgeny Tarasov

    You should fix it. I don't see any technical restrictions why you can't do this.

    1. Key to account is one to many relationship
    2. Key to repository is one to many account

    When user make push or pull you know the repository and you know authorized_keys. You can check identity and allow/disallow this action.
    Case when several accounts correspond to the public key is theoretically possible. But i don't know real scenarios when i'll register keys in this way *. Anyway, in this case you have 2 options:

    • reject action with reasonable error text. I think that everyone would be happy due to *
    • allow action if multiple accounts match. I'm not sure bitbucket can do this because possibly you need exact identity to process request...
  17. Erik van Zijst

    @Evgeny Tarasov if the key has a 1-many relationship to account, then it is impossible for us to unambiguously authenticate the user. This is a requirement, as the log entries and audit trail left by a request and possible side effects (notifications) need a user.

    You seem to suggest a partial workaround where Bitbucket could possibly look at the different accounts that come up, look at the repo that is being accessed, see which accounts have access to that repo and then in case only one of the key's accounts fits that criterion, authenticate as that account.

    While that may be possible, I wonder how useful it would be. Many users have multiple accounts (work / personal) and it would fail when both accounts can access a particular repo. It might also give rise to confusing situations where a repo can be pulled from at one point, but then later fail because of an unrelated permission change that gave the second account access to the repo.

    A better solution would be to not use the public key as the account identifier at all. This would be possible if instead of having everybody use, have them include their username in the URL.

  18. TomsSalesSeek

    If this is so hard to fix, then could there be more important failures which we are not aware of and are hard to fix!? ... Feels bit unprofessional.
    And imagine how much it costs for magnitudes of users trying to use multiple accounts and googling around for solution.

  19. Brian Jones

    This is unfortunate as I use the GPG keys on a Yubikey to authenticate myself to SSH systems for both work and private situations. Your setup is forcing me to generate a new SSH keypair which must reside on my local machine and must be copied around to use elsewhere, as well as juggle my keys with ssh-add since I use the GPG keys for everything else.

  20. Admin Sales Quoter

    More problems with the "won't fix". If you include dependency repos you are stuck unless you make everyone that would possibly use that repo also do the ssh config file thing and all rename

  21. Petter Kjelkenes

    My temp fix to commit to another user instead... Use https as remote instead.

    git remote rm origin
    git remote add origin

    Then git push origin master

  22. alex

    Anyway, you can create another ssh keypair, and in the identity file in ~/.ssh/identity puts all identities that you want use. This way you cant add the public key into bitbucket repository,

  23. Heikki Leivo

    Wtf?!? I used Bitbucket for personal projects and found it so brilliant that I recommended that we should use it at work. And so we did - my colleaques are very satisfied. But now I am unable to use same laptop for both personal and work projects without hassling with keys. This is just bloody stoopid. -1

  24. Daniele Segato

    At this point I really doubt anyone is still reading this issue comments. I wonder if we should just all start create duplicate issues until they reconsider.

    Our company is just gradually migrating to something else, less expensive and without this moronic limitations.

  25. Ricardo Chavarria

    -1 as well. There is no technical reason to prevent binding one key to multiple repos. This has to be an implementation problem on Atlasian side and we users have to pay for the consequences.

  26. Jason Force

    -1 to won't fix as well. We use bitbucket at work so I HAVE to have my ssh key from my work laptop associated with that account. Now, I can't add this machine's key to my personal account. It appears that bitbucket has no intention of fixing this problem. I'll be moving my personal projects out of bitbucket. There's a lot of change going on where I work as well, and I'll be sure to mention this to my coworkers as we make decisions about which technologies and services we want to start/stop/continue using. There are plenty of other solutions out there that would work fine for us.

  27. Joel Ballesteros

    It seems this is an old issue that doesn't want to die.

    My case is this. I did a FULL account delete in Atlassian (supposedly deleting all services and related configuration/settings???). I forgot to remove the SSH key that's been added before deleting.

    Now, I needed to add the existing SSH key (that key is from another service I tried adding the SSH key into a new Bitbucket account and the showstopper occurs: "Someone has already registered that SSH key".

    Am I correct to assume Atlassian is not really deleting the account but only tagging it as deleted that's why it still picks up the SSH key from its database???

  28. Log in to comment