You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.