I'm trying to set my SSH private key as a secret variable of my repository. The SSH key is in this format
-----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----
The key doesn't register correctly because (I think) it spans across multiple lines and BitBucket only supports single line variables (again, I think).
I'm not sure if I'm missing something obvious, but can I use my ssh private key as a secret variable?
Currently I'm using a workaround which is to base64 encode it
cat ~/.ssh/id_rsa | base64
and then use that string as the private variable. However, there's a big issue with this approach: someone can make a new sneaky commit when I don't notice and steal my private key by adding this line to the pipeline
echo $PRIVATE_KEY_B64 | base64 --decode
Hi Mike and welcome to the community.
You are correct that Pipelines does not currently support line breaks in environment variables, which is the reason why a private SSH key needs to be encoded in order to be added as a variable.
There is a risk associated indeed; when you set up SSH in Pipelines for a Bitbucket repository (either using a variable or using the SSH keys page in the Repository settings), all users with write access to the repo will have access to the remote host.
I am quoting from our documentation, specifically for using SSH keys as a secured variable:
There are security risks associated with passing private SSH keys as repository variables:
- Repository variables get copied to child processes that your pipelines build may spawn.
- Secured variables can be retrieved by all users with write access to a repository.
We recommend that you never pass your own personal SSH key as an repository variable, but instead generate a new SSH key-pair for Pipelines that easily be disabled if it is compromised. It may also be worth using deployment variables, which you can combine with deployment permissions to control access.
If you don't want users with write access to the repo to be able to access the SSH key, you can use deployments, define the SSH key as a deployment variable and then use the option "Only allow admins to deploy to this environment" for this deployment environment (this is available for workspaces on the Premium plan).
In this case, if a non-admin triggers a deployment, the build will get paused. This way, admins can review the commits made and then manually resume the build or decide not to run it.
You can read more about this in the following blog post:
We are excited to announce the open beta program for self-hosted runners. Bitbucket Pipelines Runners is available to everyone. Please try it and let us know your feedback. If you have any issue...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events