nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Apurva Paralkar

Update as of October 21, 2026:

Hi everyone,

Earlier this year, we shared our initial Changelog announcement about the upcoming change to Bitbucket Cloud SSH access. This is an important change to improve Bitbucket’s security posture and safeguard our customers from denial of service abuse. After receiving some feedback from our customers, we have decided extend a grace period starting from the original deprecation date: November 12, 2026 to December 10, 2026. During this time, we will run a series of controlled brownouts to help teams identify and migrate any remaining usage ahead of the December 10, 2026.

During each brownout window, we will:

Temporarily block SSH traffic on bitbucket.org
Return clear error messages
Show in-product messaging wherever possible

Brownout schedule:

Please note that we are excluding weekends and holidays from this brownout schedule to avoid any disruptions during down times.

Dates	Brownout duration per window	Brownout window start times (UTC)
Nov 12, 2026	15 minutes	00:00
Nov 12, 2026	15 minutes	06:00
Nov 12, 2026	15 minutes	12:00
Nov 12, 2026	15 minutes	18:00
Nov 13, 2026	15 minutes	00:00
Nov 13, 2026	15 minutes	06:00
Nov 13, 2026	15 minutes	12:00
Nov 13, 2026	15 minutes	18:00
Nov 16, 2026	30 minutes	00:00
Nov 16, 2026	30 minutes	06:00
Nov 16, 2026	30 minutes	12:00
Nov 16, 2026	30 minutes	18:00
Nov 17, 2026	30 minutes	00:00
Nov 17, 2026	30 minutes	06:00
Nov 17, 2026	30 minutes	12:00
Nov 17, 2026	30 minutes	18:00
Nov 18, 2026	30 minutes	00:00
Nov 18, 2026	30 minutes	06:00
Nov 18, 2026	30 minutes	12:00
Nov 18, 2026	30 minutes	18:00
Nov 19, 2026	30 minutes	00:00
Nov 19, 2026	30 minutes	06:00
Nov 19, 2026	30 minutes	12:00
Nov 19, 2026	30 minutes	18:00
Nov 20, 2026	30 minutes	00:00
Nov 20, 2026	30 minutes	06:00
Nov 20, 2026	30 minutes	12:00
Nov 20, 2026	30 minutes	18:00
Nov 23, 2026	1 hour	00:00
Nov 23, 2026	1 hour	06:00
Nov 23, 2026	1 hour	12:00
Nov 23, 2026	1 hour	18:00
Nov 24, 2026	1 hour	00:00
Nov 24, 2026	1 hour	06:00
Nov 24, 2026	1 hour	12:00
Nov 24, 2026	1 hour	18:00
Nov 30, 2026	2 hours	00:00
Nov 30, 2026	2 hours	06:00
Nov 30, 2026	2 hours	12:00
Nov 30, 2026	2 hours	18:00
Dec 1, 2026	2 hours	00:00
Dec 1, 2026	2 hours	06:00
Dec 1, 2026	2 hours	12:00
Dec 1, 2026	2 hours	18:00
Dec 2, 2026	2 hours	00:00
Dec 2, 2026	2 hours	06:00
Dec 2, 2026	2 hours	12:00
Dec 2, 2026	2 hours	18:00
Dec 3, 2026	3 hours	00:00
Dec 3, 2026	3 hours	06:00
Dec 3, 2026	3 hours	12:00
Dec 3, 2026	3 hours	18:00
Dec 4, 2026	3 hours	00:00
Dec 4, 2026	3 hours	06:00
Dec 4, 2026	3 hours	12:00
Dec 4, 2026	3 hours	18:00
Dec 7, 2026	3 hours	00:00
Dec 7, 2026	3 hours	06:00
Dec 7, 2026	3 hours	12:00
Dec 7, 2026	3 hours	18:00
Dec 8, 2026	3 hours	00:00
Dec 8, 2026	3 hours	06:00
Dec 8, 2026	3 hours	12:00
Dec 8, 2026	3 hours	18:00
Dec 9, 2026	3 hours	00:00
Dec 9, 2026	3 hours	06:00
Dec 9, 2026	3 hours	12:00
Dec 9, 2026	3 hours	18:00
Dec 10, 2026	Final removal

Note:

We continue to use the same SSH host keys as before with the new SSH hostname. To ensure that you can trust these host keys, we are specifying those here for your reference.

SHA256 format

256 SHA256:FC73VB6C4OQLSCrjEayhMp9UMxS97caD/Yyi2bhW/J0 bitbucket.org (ECDSA)

256 SHA256:ybgmFkzwOSotHTHLJgHO0QN8L0xErw6vd0VhFA9m3SM bitbucket.org (ED25519)

2048 SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E bitbucket.org (RSA)

Original announcement:

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.

Comments

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.

Enrique Ramirez_itcx2m

So Atlassian can send me one or more emails weekly about AI features we have never wanted or asked for, but they can't send us an email letting us know about this change? Instead this is buried in the community forums, a few levels deep. Thanks, really.

Alex Howansky

The SSH host keys for bitbucket.org and github.com are automatically added to the known_hosts file in the images launched by pipelines.

However, the keys for ssh.bitbucket.org are not added, and if I try to add them manually via Settings > Pipelines > SSH Keys, it tells me:

Failed to add known host. Bitbucket manages the SSH fingerprint settings for ssh.bitbucket.org.

Dan Ottey

I notice that when I click "clone" in the Bitbucket UI, the git command there still contains `git@bitbucket.org`. When will this be updated to stop our users from cloning with the deprecated origin?

EDIT: I just realized my comment was a dupe but I can't find a way to delete it.

Gregory Ferland

The deadline is approaching and there is still no resolution to this:

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?

Similarly, the documentation for how to clone a repository using SSH makes no mention of the new domain. When will these sources be updated?

Andreas Messer

Fully agree. Absolutely unbelievable, the change was anounced half a year ago and the bitbucket site still supplies the old to be abandoned url.

Ian Hunter

Thanks @Matthias Gaiser _K15t_

Here's an alternative for those of us who are too lazy to even copy & paste a command in multiple clones :)

git config --global url."git@ssh.bitbucket.org:".insteadOf "git@bitbucket.org:"
git config --global url."ssh://git@ssh.bitbucket.org/".insteadOf "ssh://git@bitbucket.org/"

(Also useful in the interim while the Bitbucket Cloud clone dialog still gives the hostname we're not supposed to be using……..)

Pracplay Support

WTF? how can there 1) only be a 6 month delay for this 2) NEVER SEND AN EMAIL ON THIS MASSIVELY BREAKING CHANGE! (the only reason i'm here is bc i couldn't find something in bitbucket and an llm pointed this post out unsolicited when i referenced git@bitbucket urls)

Eemil

How can you possibly consider discontinuing bitbucket.org, when users are still being trained to use git@bitbucket.org from a much more authoritative source—the repo's own bitbucket page?

ldaughenbaugh

Put together this script to scan my local repos and update all my repos at once.

To use, save the script below as update-bitbucket.sh and run the following replacing /Path/to/GIT/Repos/ with the directory containing your local repositories.

# Make the script executable
chmod +x update-bitbucket.sh

# Preview changes without modifying anything
./update-bitbucket.sh /Path/to/GIT/Repos/ --dry-run

# Actually update the repositories
./update-bitbucket.sh /Path/to/GIT/Repos/

#!/bin/bash

SEARCH_DIR="${1:-$HOME/Sites}"
DRY_RUN=false

if [[ "$2" == "--dry-run" ]]; then
    DRY_RUN=true
fi

echo "========================================"
echo " Bitbucket SSH Remote URL Migration"
echo " Directory: $SEARCH_DIR"
echo " Mode: $([[ "$DRY_RUN" == true ]] && echo "DRY RUN" || echo "LIVE")"
echo "========================================"

updated=0
skipped=0
failed=0

while IFS= read -r -d '' gitdir; do

    repo="${gitdir%/.git}"

    while IFS= read -r remote; do

        old=$(git -C "$repo" config --get "remote.$remote.url")

        # Only update old Bitbucket SSH URLs
        if [[ "$old" == git@bitbucket.org:* ]] ||
           [[ "$old" == ssh://git@bitbucket.org/* ]]; then

            new="${old/bitbucket.org/ssh.bitbucket.org}"

            echo
            echo "Repository: $repo"
            echo "Remote:     $remote"
            echo "Old:        $old"
            echo "New:        $new"

            if [[ "$DRY_RUN" == true ]]; then
                echo "Status:     WOULD UPDATE"
                ((updated++))
            else
                if git -C "$repo" remote set-url "$remote" "$new"; then
                    echo "Status:     UPDATED"
                    ((updated++))
                else
                    echo "Status:     FAILED"
                    ((failed++))
                fi
            fi

        else
            ((skipped++))
        fi

    done < <(git -C "$repo" remote)

done < <(find "$SEARCH_DIR" -type d -name .git -prune -print0)

echo
echo "========================================"
echo " Migration Complete"
echo " Mode:    $([[ "$DRY_RUN" == true ]] && echo "DRY RUN" || echo "LIVE")"
echo " Updated: $updated"
echo " Skipped: $skipped"
echo " Failed:  $failed"
echo "========================================"

if [[ "$DRY_RUN" == true ]]; then
    echo
    echo "No changes were made."
    echo "Run without --dry-run to apply updates."
fi

adamy

This seems like a pretty big disruptive change to drop on everyone next to no notice.

Reconsider and roll this back - plan a better transition and give much more time to be respectful.

The email today was the first notice I received for this.

Nathan Phillip Brink

I am surprised at a number of things that have mostly been mentioned:

Bitbutcket itself isn’t advertising the new hostnames.
The article actually tells you to sed -e s/bitbucket.org/ssh.bitbucket.org/ on https://bitbucket.org/site/ssh . Not only does this mean that https://bitbucket.org/site/ssh itself isn’t updated yet, but that regular expression will replace ssh.bitbucket.org with ssh.ssh.bitbucket.org once they do update it. Not to mention the nit that a regular expression of bitbucket.org will also match blah-bitbucket-org-etc.example.com (in practice this won’t really happen but whatever).
The article has very weird highlighting on it. It even shows an attempt to add the weird highlighting inside of a <code/> block: <mark data-is-hovered="false" data-has-focus="false" data-mark-annotation-state="resolved" data-id="8952817d-9e60-4e8b-9dc9-2c14921025a6" data-mark-annotation-type="inlineComment" data-mark-type="annotation" data-renderer-mark="true" aria-disabled="true">ssh.bitbucket.org</mark> see

I am personally planning on waiting until I get errors to update my repositories. It doesn’t seem like Bitbucket is actually ready for this change.

Wolf

Separating SSH and HTTPS makes sense, but the timeline doesn’t have to break existing workflows in a few weeks. You can do this without breaking the workflows of millions of users, by using port forwarding on your edge routers, then giving more time to transition.

Josué Garcia

SO I have to change all of my 100+ jenkins jobs and pipelines? Great 😫

David Rolston

The lack of consideration of impact on your customer base with no investment or preparation on the part of Atlassian is mind boggling. You haven't even updated the bitbucket.org UI.

Andy Del Campo

Absolutely inappropriate deadline especially over the holiday season, push it out to next year and improve your communications, this should have been plastered all over the admin console as soon as the decision was made to replace the ssh hostname. You guys are out of line on this one.

Fernando José La Calle Prada

A quick question: does this change affect the IPs that the CI/CD process uses to connect to the server for deployments? I assume it doesn’t, right?

Kevin Fries

Will the Bitbucket-provided variable name BITBUCKET_GIT_SSH_ORIGIN be updated to the new value, for pipelines that explicitly set their remotes?
e.g.

script:

  - git remote set-url origin ${BITBUCKET_GIT_SSH_ORIGIN}

Jason Rumney

After updating the URL, I do not appear to have the same access to the repositories that I had on the old working URL. Are you sure this change is ready to roll out in four weeks time?

Command failed with error #128!
COMMAND git ls-remote '********' 'refs/*'
STDOUT (empty)
STDERR Warning: 
Permanently added 'ssh.bitbucket.org' (ED25519) to the list of known hosts.
git@ssh.bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

[Edit] it looks like this is going to be even more work than it at first appears, as the private keys get disassociated from the remote when the URL is changed in the client software I am having to update around 150 repositories in.

Dominik Feiler

As others have said. Why does the "Clone this repository" still provide me with
git clone git@bitbucket.org:<workspace>/<repo>.git ?

matthewrhamilton

I just added the following to my ~/.ssh/config file…

Host bitbucket.org
  HostName ssh.bitbucket.org

Then did a pull on an existing repo and accepted the new host after verifying the fingerprint. It won't work with everything, but might be worth a try for anyone that doesn't want to change all their repositories over.

ccenvcvb

I think this quote is appropriate

Prostetnic Vogon Jeltz broadcasts the official demolition notice for Earth across the star system. When an Earth transmission attempts to protest, the Vogon captain dismisses their surprise, noting that the plans have been on display in Alpha Centauri for fifty years. Because the residents failed to check the local planning office four light years away, the captain orders the immediate energization of the demolition beams.

I have no time to read up on bitbucket community, I just need bitbucket to be operational.

A couple of months ago we had an issue with https auth and together with Atlassian Support we decided to move all remotes from https to ssh.

Not a single mention at that time that the URL would change.

So I guess this notification is hidden so well that even support is not aware of it.

Just checking if the posting date wasn't April 1st.

Jim Nicholls

For me bitbucket.org and ssh.bitbucket.org do resolve to different IPs.

Jim Nicholls

The documentation for configuring SSH and two-step verification also still refers to bitbucket.org instead of ssh.bitbutcket.org.

Jim Nicholls

I thought I had this problem as well. It turns my Git client (GitKraken) knowns bitbucket.org is BitBucket and to use its BitBucket SSH key pair. But doesn't know ssh.bitbucket.org is BitBucket and uses a different SSH key pair. Hence the permission denied for me.

mjkaldin

My view of Atlassian just grows more and more towards that they are a cowboy company that just want you to pay them more money. First they removed the possibility to buy additional build minutes on the free plan, and now this. We use git submodules in our repositories. And we build our releases from inside version controlled docker images. Hence, all existing releases will no longer be rebuildable after Nov 12. To be able to rebuild them we must either change the URL of the submodule, which is version controlled. Or, we must update the docker image, which is also version controlled, to replace SSH URL bitbucket.org with ssh.bitbucket.org. So, repeatability goes down the drain. Thanks so much, Atlassian! But, perhaps we should utilize the lack of write protection for tags, which Atlassian have been refusing to implement for years (see

https://jira.atlassian.com/browse/BCLOUD-10967

), to just move all existing release tags?!?

Falk Köppe

We are hosting private npm packages on Bitbucket and give them a commit tag to then install them with npm install bitbucket:<workspace>/<package>#<tag> in our NodeJS application. This adds an entry in the package-lock.json file, similar to

"node_modules/<package-name>": {
  "version": "<tag>",
  "resolved": "git+ssh://git@bitbucket.org/<workspace>/<package>.git#<sha>"
},

Unfortunately, the resolved URL is not correct, because it should have the ssh subdomain.

Therefore, the npm install command needs to be changed to the longer

npm install git+ssh://git@ssh.bitbucket.org/<workspace>/<package>#<tag>

With the proposed change, the npm install bitbucket:… syntax would be broken. https://docs.npmjs.com/cli/v8/commands/npm-install#:~:text=install%20gist%3A101a11beef-,npm%20install%20bitbucket%3A,-%3Cbitbucketname%3E/%3Cbitbucketrepo%3E%5B%23%3Ccommit

Alexander Schomburg

@Apurva Paralkar You're kidding us, right? With just a month in advance we were just informed about this massive and mostly unnecessary change. We deploy everything through SSH, nobody uses HTTPS for automatic git deployments. All our customers websites, all CI/CD integrations, everything. This is going to take hours of work and talking with external IT to fix. What the actual fuck? Read the comments of all the other frustrated customers in this thread and rethink your approach! We are now actively considering moving to our own self-hosted repository solution as this is about the same effort as switching the SSH domain for all instances…

martonmiklosqdev

WTF?! We have tons of repos with submodules added with ssh config. This means we will not be able to check out older commits without manually checking out submodules.

Gregor Sondermeier

I think this decision and the short notice is a bit dangerous for bitbucket's and/or node.js' reputation.

The impact is big, but the Node/npm ecosystem doesn't seem to know it yet. If you look at e.g. https://docs.npmjs.com/cli/v12/configuring-npm/package-json or https://docs.npmjs.com/cli/v12/commands/npm-install , as of right now it is documented as perfectly fine to use the bitbucket: shorthand for referencing dependencies that are hosted directly on bitbucket. But for SSH, when the dependency is resolved, that shorthand is not expanded to ssh.bitbucket.org at this point in time. It is only expanded to bitbucket.org. Which will presumably throw errors after November 12 and confuse a lot of people.

Additionally, as others have pointed out, internal bitbucket documentation lists ssh.bitbucket.org merely as an alternative for bitbucket.org, not as a substitution. If at all. Even the "Clone this repository" doesn't show ssh.bitbucket.org.

Ideally, npm and other package managers will receive updates soon which informs them to expand bitbucket: shorthands to ssh.bitbucket.org. which I don't know how fast these things go. And then people will need to actually use these newer versions, which will take I don't know how long.

Nick Crebbin

This has been really badly managed, why such short notice? Letting Bitbucket users know the same time as admins is not helpful. You have just created a massive amount of work for your user base and left them with very little time to do it.

Klaudia Pawelek

Is altssh.bitbucket.org going to be affected as well? The article does not mention that, but I'd like to be extra careful and get some confirmation if possible. Thanks!

sakai-kousaku

If you publish an important article, we would appreciate it if you could also notify us by email at the same time.
If the subject line begins with "Action required:", we will make sure to read it.
Thank you.

andrea.flores

I had to unsubscribe from all of them because it was so annoying, can't believe this was posted in May and I just received an email TODAY.

Anders Harder

Note if you have specific ssl key in your .ssh/config file:

I.e. my entry:

Host bitbucket.org
AddKeysToAgent yes
IdentityFile ~/.ssh/bitbucket_work

(which I needed to duplicate as 'Host ssh.bitbucket.org')

Michael Tran

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.

See the post.

Michael Tran

I'd like to know as well, but it still seems valid that non-ssh is supported for read-only repos.

Michael Tran

Seems like a good solution for legacy Windows users. With Unix or OpenSSH client, ssh config file ( ~/.ssh/config ) can do something similar with identities.

Fernando José La Calle Prada

I was referring to this (https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/); as I understand it, this change does not involve adding more IP addresses to the list of allowed IPs.

Natanael

That's the most weird part of this "migration". Makes no sense.

istvan.verhas

Thanks @Matthias Gaiser _K15t_ and @Ian Hunter

One more, simple solution on the ssh configuration level as the following in ~/.ssh/config file:

Corporate Bitbucket Account

Host bitbucket.org-work
HostName ssh.bitbucket.org
User git
IdentityFile ~/.ssh/id_ed25519_work.pub
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
IdentitiesOnly yes

Personal Bitbucket Account

Host bitbucket.org-personal
HostName ssh.bitbucket.org
User git
IdentityFile ~/.ssh/id_ed25519_personal.pub
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
IdentitiesOnly yes

As I use two different accounts on the Bitbucket already, the only change is apply in this config. @Michael Tran did you refer something like this?

If you have only one account and until now used only the bitbucket.org as the clone url you can accomplish this way

Host bitbucket.org
HostName ssh.bitbucket.org
User git
IdentityFile ~/.ssh/id_ed25519_bitbucket.pub
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"
IdentitiesOnly yes

and sure the 1password is optional and can changed with any other supported credential provider.

istvan.verhas

If you configure the ssh then does not matter the number of repos and also work with submodules. Look at my hint at

https://community.atlassian.com/forums/discussion/comment/3302914#Comment_3302914

Wolf

They did for me, with that subject. On 2026-10-15.

Nathan Phillip Brink

That is also when I was alerted to this article. However, this article says it was originally published on 2026-05-12.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud