How do you configure SSH keys and access keys in Bitbucket?

Think of SSH keys as two types of building passes. A personal SSH key is like an employee badge that works on every door the employee is authorized for. An access key is like a visitor badge that only opens one specific room and cannot make changes (read-only).

SSH keys in Bitbucket provide passwordless authentication for Git operations over SSH. Personal SSH keys are added to your Bitbucket account settings and authenticate you as that user for all repositories you have access to. When you run 'git clone [email protected]:workspace/repo.git,' Git uses your SSH key to prove your identity. You can add multiple SSH keys to your account, one for each machine you work on. Bitbucket supports RSA, ECDSA, and Ed25519 key types, with Ed25519 recommended for its security and performance.

Access keys (also called deploy keys in other platforms) are different. They are added at the repository level and grant read-only access to that specific repository. They are not tied to a user account, making them ideal for CI/CD systems, deployment servers, or any automated process that needs to clone the repository but should not be able to push changes. Access keys can optionally be granted write access, but read-only is the default and recommended configuration. In Bitbucket Data Center, you can also add SSH keys at the project level, granting access to all repositories in the project.

In production, the typical setup involves personal SSH keys for developers and access keys for infrastructure. A deployment server cloning multiple repositories would need an access key added to each repository, which can become cumbersome at scale. For Bitbucket Pipelines specifically, you do not need to configure SSH keys manually because the pipeline environment automatically has access to the repository. However, if your pipeline needs to clone additional private repositories (like shared libraries), you configure an SSH key pair in the Pipeline settings, and the private key is automatically available during builds.

A common gotcha: if you regenerate an SSH key on your laptop but forget to update it in Bitbucket, you will get 'Permission denied (publickey)' errors. Another mistake is using a personal SSH key on a shared server (like a Jenkins agent), which grants that server access to all repositories the user can access. Always use access keys for shared infrastructure to follow the principle of least privilege.