Upcoming change to Bitbucket Cloud SSH access: move from bitbucket.org to ssh.bitbucket.org

[#1]

As part of our security and anti-abuse posture, we are making an important change to how SSH traffic is handled for Bitbucket Cloud. If you use Git over SSH with Bitbucket today, you’ll need to update your configuration by November 12, 2026 to avoid disruption.

What’s changing?

Bitbucket Cloud is separating SSH and HTTPS traffic so that:

• bitbucket.org will serve only HTTPS traffic (web and API)

• All SSH-based Git operations must use a new hostname: ssh.bitbucket.org

This change affects Git over SSH only. Common SSH operations that will be impacted include:

• git clone (over SSH)

• git pull

• git fetch

• git push

If you currently use SSH URLs that look like:

git@bitbucket.org:<workspace>/<repo>.git

you’ll need to update them to use:

git@ssh.bitbucket.org:<workspace>/<repo>.git

HTTPS access is not affected. URLs such as:

https://bitbucket.org/<workspace>/<repo>.git

will continue to work as they do today.

Why we are making this change

By splitting SSH and HTTPS traffic onto separate hostnames, we can:

• Apply more advanced and tailored security protections specifically to Bitbucket’s public web and API endpoints (bitbucket.org)

• Better isolate different types of traffic, improving resilience and scalability over time

• Reduce the blast radius of certain classes of attacks by separating protocols

In short, this is part of ongoing work to harden Bitbucket Cloud’s security posture and improve reliability for all customers.

What you need to do

If you use Git over SSH with Bitbucket Cloud, you’ll need to:

1. Update SSH remote URLs

For each repository that currently uses an SSH remote pointing at bitbucket.org, update the remote URL to use ssh.bitbucket.org instead.

From within your local clone:

git remote set-url origin git@ssh.bitbucket.org:<workspace>/<repo>.git

Repeat this for each remote or repository that uses SSH and bitbucket.org.

You can confirm your current remote configuration with:

git remote -v

Look for any entries that include git@bitbucket.org: and update them.

2. Trust the new SSH host key

The first time you connect to ssh.bitbucket.org, you’ll be prompted to verify and accept its SSH host key. When you see the prompt, review the fingerprint and, if it matches Bitbucket’s published values, choose “yes” to continue. This will add the host key to your ~/.ssh/known_hosts file.

If you prefer to pre-seed your known_hosts file (for example, in automated environments), you can manually add the ssh.bitbucket.org host key there in advance.

You can use the following command in the automation to add the host keys of the new server:

curl -s https://bitbucket.org/site/ssh | sed 's/bitbucket.org/ssh.bitbucket.org/' >> ~/.ssh/known_hosts

3. Update CI/CD pipelines and automation

Any automated system that uses SSH to interact with Bitbucket Cloud will also need to be updated. This includes:

• CI/CD pipelines

• Deployment scripts

• Build servers

• Mirroring/synchronization jobs

• Any internal tooling that runs git clone, git fetch, or git push over SSH

Search your configuration for git@bitbucket.org: or ssh://git@bitbucket.org and update those references to git@ssh.bitbucket.org:.

4. Adjust network/firewall rules if needed

If your organization restricts outbound SSH connections via firewalls or security appliances, ensure that ssh.bitbucket.org on port 22 is allowlisted.

You may need to:

• Add ssh.bitbucket.org to your outbound allowlist

• Update any hostname-based rules that currently reference bitbucket.org for SSH

• Coordinate with your network/security team to roll out the change across environments

If your network blocks port 22, Bitbucket provides an alternate hostname and port combination you can use. Follow the directions at Port 22 is blocked on local network | Bitbucket Cloud | Atlassian Support.

Timeline

This change is being announced now, and customers will have until November 12, 2026 to complete their migration.

• During this migration window, SSH access via bitbucket.org will continue to work, but you should start updating to the new SSH server ssh.bitbucket.org as soon as possible.

• After the migration period ends on November 12, 2026 , SSH connections to bitbucket.org will be refused. At that point, any Git operations over SSH that still target bitbucket.org will fail until they are updated to use ssh.bitbucket.org.

We encourage you to complete these updates well before November 12, 2026 to avoid last-minute issues.

Need help?

If you have questions about this change, run into issues updating your remotes, or need guidance for complex/large-scale environments:

• Comment on this post with details of your setup

• Or contact Atlassian Support via your standard support channels

We’ll monitor feedback and update this post with any additional clarifications or common troubleshooting tips as needed.

[Matthias Gaiser _K15t_]

In order to make it simple to switch a repo to the new host, I've created this little shell command for me:

old=$(git remote get-url origin) && \
new=$(printf '%s\n' "$old" | sed -E 's#(^|@|//)bitbucket\.org([:/])#\1ssh.bitbucket.org\2#') && \
echo "old: $old" && echo "new: $new" && \
git remote set-url origin "$new" && git remote -v

[R_Hummel]

One question regarding the migration timeline:

Currently, when opening the “Clone this repository” dialog in Bitbucket Cloud, the SSH clone URL still uses the old hostname:

git@bitbucket.org:/<repo>.git

According to this announcement, SSH access must migrate to:

git@ssh.bitbucket.org:/<repo>.git

Do you plan to update the clone dialog automatically at some point before the migration deadline? If yes, is there already an estimated timeline for when the Bitbucket UI will start showing the new SSH hostname?

This would help avoid confusion for developers creating new clones during the migration period.