1. Bitbucket
  2. Public Issue Tracker
  3. master

Issues

Issue #5154 wontfix

Someone has already registered that SSH key.

Boris Cosic
created an issue

Hi, 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.

Thanks Boris

Comments (70)

  1. Marcus Bertrand [Atlassian] 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. spinitron

    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 bitbucket.org host.

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

    Host bitbucket-alt
        User git
        Hostname bitbucket.org
        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 git@bitbucket.org 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 staff

    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. Istvan Chung

    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. 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!

  14. Michael Gane

    Can't we at least be allowed this for deployment keys? One deployment server, isn't allow the key in multiple repos. Would be really useful for webhosts / development teams.

  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 staff

    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 git@bitbucket.org:user/repo, 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 bitbucket.org

  21. Log in to comment