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

Issues

Issue #9242 resolved

Ability to control SSH keys down to specific repositories/teams

klj613
created an issue

Ability to control SSH keys down to specific repositories/teams

e.g. I'm on 5 teams however I only want one of my SSH keys to work on repository-ABC or TEAM-XYZ.

Reason: Better security. SSH key per team/company/repository etc.

Comments (12)

  1. Erik van Zijst staff

    In Bitbucket, SSH keys are used to identify the user (when pushing over ssh, you don't provide your username -- your public SSH key points to your account).

    As such, to achieve what you want, you'd have to create separate accounts and use the appropriate when pushing to a repo. This is of course less than ideal, but using host sections in ~/.ssh/config you might be able to automate some of that.

    Another thing you could look at are Deploy Keys. These are SSH keys that are not linked to user accounts, but are put on a repo directly. The only real down side with regards to your workflow would be that deploy keys are strictly read only and so you would only be able to pull, not push.

    Now before I go and raise an internal issue for this, I'd like to understand the use case a bit better. In what way do separate SSH keys improve security over assigning access permissions to individual users on each repo/team?

  2. klj613 reporter

    It is a concern I have knowing that all my personal SSH keys (on my PC, laptop, jenkins VM etc) have pull/push access to all my teams (e.g. employer?) and my work SSH key having access to personal repositories.

    I like to keep personal and work separate (I actually like to keep each repo/project separate). Also knowing if one of my keys gets exposed then only a subset of repositories were exposed. e.g. if my personal jenkins server gets hacked then that key will be able to access my employer's repositories.

    I know I can create multiple users but like you say that is less than ideal.

    This is a use case and is not a current issue as I am only starting to use BitBucket now more. It is also an issue on GitHub though :)

  3. Erik van Zijst staff

    It is a concern I have knowing that all my personal SSH keys (on my PC, laptop, jenkins VM etc) have pull/push access to all my teams (e.g. employer?) and my work SSH key having access to personal repositories.

    Quite a few people have 2 accounts for that reason. They have one personal account and one for work. Each has a different SSH key and since their personal account is not a member of their employer's teams, the two are completely isolated.

    Also knowing if one of my keys gets exposed then only a subset of repositories were exposed.

    True. If you are not doing so already, I strongly recommend adding a password to your private keys so that even if your machine gets hacked/stolen, your SSH keys are not compromised.

    By the way, if a hacked/lost computer is a concern, you should also consider that your browser's session cookies can be stolen and these too will give a hacker full access to your account (and by extension your employer's repos). Cookies do not support passwords and so this vector is likely a bigger risk than an SSH key.

  4. Steve Steiner

    I have a very specific use-case.

    I deploy client websites owned by a particular Unix user e.g. mycustomer user owns http://mycustomer.com which is in /home/mycustomer/public_html.

    I want to be able to save changes to the website from either my local installation (using my main account key), and I also want to be able to save changes from the deployment target (mycustomer/public_html). For obvious reasons, I don't want to add mycustomer's SSH key to my account; I only want them to be able to access their one repository.

    A deployment key doesn't do it, because I need the ability for mycustomer's account to push changes to the repository.

    Creating a new account for each customer would be prohibitively time-consuming and, since BitBucket doesn't allow the same key to be used in multiple accounts, I'd have to have a separate key for each account.

    I'm amazed that a solution to this use case hasn't ever gotten real attention since I'm sure this comes up all the time...it comes up with me every day and is a huge annoyance.

    Steve

  5. Steve Steiner

    Also, the inability to add a key formerly used as a deployment key means that you can't temporarily "promote" a key by adding it your account, then "demote" it to deployment key for maintenance.

  6. Log in to comment