1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #4155 wontfix

Same SSH key for different accounts

created an issue

I have a user account and a team account and it is impossible to use the same SSH key for both. It is understandable with different user accounts but very annoying with team accounts. Do you intend to allow same ssh keys for user and team accounts?

Comments (24)

  1. Marcus Bertrand staff

    Can you explain the use-case where your SSH keys would need to be on the team account? If you have access to the specific team via group permissions, you should have the ability to access any of the repos you own or the team owns.

  2. Thiago Souza

    I have access to a specific team via grous permission (admin role) and the group are in repository access management with admin role too. I already have a ssh in my personal account and is working in my personal repos.

    But when i try push to a team repo the console ask me to:

    git push -u origin --all
    Password for 'https://tentaculoit@bitbucket.org':

    If a put the password works, but my ssh key already is in my personal account why is asking for the password?a


    I am also confused about how this works. I have a personal account with ssh keys added so I can use mercurial to pull/push.. I am also an admin of a team account that several repositories.. I would like to use ssh to push/pull from them also.. When I try to add my personal key to the team account, it will not let me. I would think that any team member would be able to use their personal ssh keys for interacting with team repos.. Thanks!

  4. Kevin Francis

    I seriously have no idea how this entire Team thing works. I've added my new SSH key under my personal account and still can't access the repository. I doubt I have to add the key under the Team identity, as I'm already part of the team and have my own keys.

    Some documentation / guidance would be really great, or at least an explanation here.

  5. Anthony Ettinger

    exactly . its like they don't even use their own product to not allow the same key on 2 accounts. if you're going to do that, at least give me the ability to send email notifications to different addresses based on team/project.

  6. Lyle Scott

    I am in the same boat as Michael Strelan. I have a work account that I just happen to have my laptop added to in addition ti my work station. And i have my personal account . I just switched from github but this is caused me some headache

  7. Pierre-François Clement

    Same here as pretty much everybody else who has to deal with two Bitbucket accounts being used on the same computer. I don't get why you wouldn't allow the same public SSH key to be associated with more than one account? You could send a notification or ask for approval from all the users who have the same key if it's for security reasons.

    Anyway, I was about to give Bitbucket a go for my personal projects, but I guess I'll have to stick with Github and Gitlab instead as I don't happen to have a "work" account on those platforms.

  8. Doug Freed

    Presumably this is because the auth system currently cannot handle multiple users with the same SSH keys. The only way this can be improved would be to make it so that if multiple users have the same SSH key, when you auth with that key, you get the permissions of all users with that key. However, this is not a good idea. Why? Because you shouldn't be sharing keys between machines, nor between roles. Sharing keys between machines increases the probability that the key will get compromised (if you do it right, this probability is still low, but it still increases for each machine you put the same key on). Once a shared key is compromised, not only do you have to kill it on every service you use it for, but you also have to go to every machine to update to the new key. Sharing keys across roles is bad for the same reason, but is actually worse, because once it's compromised, the attacker has a lot more permissions than they would have.

    Taking this a step further, you should have 1 key per machine, per role, per service. Sure, this sounds like a lot of keys to manage, but it really isn't. You can easily run multiple ssh-agents (your keys are encrypted on disk, right?), and just change SSH_AUTH_SOCK in your environment to point to the right agent as needed. You can even name the sockets something handy using ssh-agent -a /path/to/socket, allowing you to name sockets by role and service on your machine. If a key is compromised (single key compromise is more likely than all the keys on a machine being compromised. People make mistakes; see http://www.theregister.co.uk/2013/01/25/github_ssh_key_snafu/), you need only update 1 key in one location, and you only have to tell 1 service that the key changed. The end result? A key compromise only gives an attacker limited access, and the trade-off is only slightly less convenience.

    Regarding pushing to team repositories, you can do so under your individual account provided you have write or admin access to the repository under the team, in the same way you would with repositories under an individual's account. The team account as a Bitbucket login no longer works (as of 2014-02-21 at least; see https://confluence.atlassian.com/display/BBKB/Team+Account+Changes), and so all administration must be, and pushing/pulling should be, done from an individual account that has the necessary level of access to the repositories of the team. I have one team that I created, and am in the administrators group, which has full admin access to the entire team. I have one repository in that team, which is private, and I've pushed code via SSH as my user without issue. If you're using HTTPS for push/pull to work around restrictive firewalls that block SSH, you should be using your individual username, and you will have to type your Bitbucket password every time, because SSH keys do not work with HTTPS (this is likely the issue that Thiago Souza and Sears PHP Team were running into). If you don't have a restrictive firewall blocking SSH, you really should be using SSH, as it's a much better access method, and doesn't require you to type your Bitbucket password for every repository operation (which, for git, includes git remote show <remote>).

    TL;DR: one SSH key per machine, per role, per service. Pushing and pulling from team repositories is exactly the same as using another individual's repositories.

    On an unrelated note, one of these days I'm going to have to make the trip up to the SF office and buy you guys a round. I recently moved to the Silicon Valley area, so now that's much more feasible. Bitbucket is still better than Github, and Atlassian continues to produce wonderful products (I use Bamboo, and have had the opportunity to play with Stash). Keep being awesome!

  9. Pierre-François Clement

    Sounds good in theory, but in practice you often do not get the chance to know when, which, where or how a key has been compromized, so if I were to suspect it happened to one of my keys, I would change them all and on every single service I use them for, just in case. Imho the best protection is to make a habit of regularly changing your keys, the higher the frequency, the better the security. In such a scheme, I think it's secure enough to have a single SSH key per machine, and I think you could imagine the pain in the ass it would be to change all of my keys once per month if I had one per machine, role and service as you suggest.

    I think it's only a matter of taste after all, and both security schemes are valid enough not to arbitrarily decide to favour one and prevent the other, especially on a platform as Bitbucket.

  10. Rodrigo Farias Rezino

    In my case I have an professional account (owned by company) and I use my particular machine to work with the projects and I have an a personal account. And I can't register the same ssh to access the different projects personal and professional.

  11. Shea Martin

    I just use more than one key, one for work, and one for personal. I use Putty Ageant, so I don't have to log in all the time. Then in hgrc, under [ui] add an alias for ssh, and add a command line option to specify which key to use for that repository:

    ssh = TortoisePlink.exe -ssh -2 -batch -C -i H:\Users\myname\.ssh\my_company_private_key.ppk 

    It is kind of annoying to have to change the hgrc after cloning, but workable. But I have since decided to just merge my personal and work. All my work code goes under a team, so not a big deal, and my personal stuff just remains under my name.

  12. Thomas Fotheringham

    Setup a new host name for the same IP address in /etc/hosts bitbucket2.org

    and then modify (or add) your ~/.ssh/config

    Host bitbucket.org

    IdentityFile ~/.ssh/id_rsa

    Host bitbucket2.org

    IdentityFile ~/.ssh/id_rsa_extra

    Then clone your repo agin using bitbucket2.org

  13. Anonymous

    I was faced with an insurmountable problem when one project needed to use the repository from another account on the same computer. There are no teams and any other computers. It turns out that it is necessary to look for another place for my projects. You want to think about his theories, but I'm not going to stop their business.

  14. Allen Luce

    I've both a personal account and a work account. And maintain a unified personal repo for shell, emacs, tmux, and other development configs. I develop for both the company and my own personal projects.

    My choices:

    1) Host personal repo on Bitbucket. Requires that I either put my personal SSH key on my work computers, or my work SSH key on my personal computers. Neither is ideal.

    2) Host personal repo on Github. Kind of a no-brainer at this point.

    3) Maintain two repos. Violates DRY, leads to needless effort and inevitable divergence. Creates a mental dichotomy and forces a choice: for whom do I perform substandard work, myself or the company? The choice may be obvious.

  15. Doug Freed

    Allen Luce, if your work account was on Github, you'd have the same problem as you have now on Bitbucket, because Github has this same problem. If your configs don't contain any sensitive information (from the sounds of it, they probably don't), just make the repo public, and then you can clone it as whatever user you want. You could also easily give your work user commit access to the repo.

  16. John Garcia

    Ideally, you would have one user that owns your repos and has access granted to the company repos. In lieu of that, do what Doug said in the last line. Since we give you 5 free users with your unlimited free repos, you can just add your work user to your personal repos as you like. I'd also like to point out that this security feature is not a problem at all, please stop calling it that. Using the same SSH creds for two accounts is not a great practice considering how inexpensive they are to generate.

  17. Log in to comment