Everything running smooth, right?

Until the console, instead of giving you that sweet, administrative silence we devs love so much, decides to spit out a nasty little passive-aggressive heads-up:

Starting November 12, 2026, Bitbucket is moving SSH traffic to ssh.bitbucket.org. 
Change your host name now to avoid connection disruptions.

(Dramatic silence. Long sip of coffee).

If you’re the kind of dev who closes the tab thinking “I’ll deal with this later, it’s just corporate noise”, hit the brakes right now. Because this time, the folks at Atlassian aren’t bringing fireworks or customer satisfaction surveys: they’re coming with bolt cutters for your network cable.

The hostilities kick off tomorrow. And unless you tweak a couple of silly lines, your CI/CD pipeline or your 1:00 PM deploy will blow up in the sneakiest, most cowardly way known to modern computing: the intermittent bug.

📦 What the hell is Atlassian actually changing?

Let’s cut to the chase—no corporate fluff.

1. SSH is moving next door: All Git SSH traffic stops working on bitbucket.org and moves exclusively to ssh.bitbucket.org.
2. HTTPS stays put: The web interface, REST API, and HTTPS clones aren’t going anywhere; they remain on bitbucket.org.
3. Same host keys, guaranteed warning: Even though Atlassian uses the exact same fingerprints for both hosts, your local SSH client treats ssh.bitbucket.org like a total stranger if you only had bitbucket.org on file. So yes: the first time you hit it, that authenticity warning will slap you right in the face.

Why pull this move now? In their official announcements, they just hand out the cutoff dates and the new domain without breaking a sweat. Classic move: zero trenches-level explanations. Most likely (and this is pure battlefield deduction after years of dealing with saturated infrastructure), they want to decouple the massive firehose of SSH connections from web traffic and load balancers. That way they can scale and manage it independently without a sudden traffic spike bringing the entire platform to its knees.

😱 The fingerprint prompt: Don’t panic (well, maybe just a little)

If you tried jumping ahead of the apocalypse by testing the connection to ssh.bitbucket.org, your terminal probably dealt you that classic security backhand:

Plaintext

The authenticity of host 'ssh.bitbucket.org (…)' can't be established.
ED25519 key fingerprint is SHA256:y9wnk5p5e6eQJ6K…
Are you sure you want to continue connecting (yes/no/[fingerprint])?

(That exact microsecond where your heart skips a beat and you wonder: “Am I getting Man-in-the-Middle’d from a basement in Vladivostok, or did these guys swap their keys without telling anyone?”).

Deep breath, everyone: The public keys are totally legit. But since your SSH client has never talked to the ssh.bitbucket.org subdomain before, your local ~/.ssh/known_hosts file doesn’t have it on record, so it raises the alarm.

To get it rock-solid and avoid blindly typing “yes” on every single server like a maniac, add Atlassian’s official fingerprint by hand before your unattended deploy scripts get stuck waiting for an interactive prompt that will never arrive:

Bash

# Clean up any leftover junk from previous attempts just in case
ssh-keygen -R ssh.bitbucket.org 2>/dev/null

# Fetch Bitbucket's official host keys and append them to known_hosts
ssh-keyscan -t ed25519,rsa ssh.bitbucket.org >> ~/.ssh/known_hosts

Veteran dev golden rule: Don’t just trust my command or what some random guy posts on a forum. Head over to Atlassian’s official documentation (bitbucket.org/site/ssh) and verify with your own eyes that the hash matches character by character.

💣 The medieval torture of “Brownouts” (how to lose your mind debugging)

Atlassian isn’t pulling the main breaker all at once. That would be far too merciful. Instead, they’re using the toxic partner playbook: progressive scheduled outages (brownouts).

Basically, they will intentionally drop SSH service on bitbucket.org during specific time windows four times a day (at 00:00, 06:00, 12:00, and 18:00 UTC), Monday through Friday:

Dates (2026)	Outage Window Duration	State of your mental health
Nov 12–13	15 minutes	“Weird, must’ve been a temporary Wi-Fi glitch”
Nov 16–20	30 minutes	“Hey, Capistrano timed out once, but went through on retry”
Nov 23–24	1 hour	“Restarting the VPN just to be safe”
Nov 30 – Dec 2	2 hours	Full-blown panic in the Slack channel
Dec 3–4 & 7–9	3 hours	Pure, unadulterated despair
December 10	Game over	Total blackout of SSH on the old host

(They’re skipping weekends and giving a truce from November 25 to 27 for Thanksgiving—how thoughtful of them).

See the trap? If you trigger a deployment at 1:05 PM, your Capistrano, Ansible playbook, or CI/CD runner will faceplant hard during the git checkout. Ten minutes later you rerun the exact same job, it goes through like a charm, and you spend the next half hour staring at network logs like a cow watching a train go by, swearing up and down because you’re convinced your hosting provider’s switches are possessed.

And come December 10th… that’s it. If you haven’t migrated, you don’t deploy. Period.

🛠️ Down to business: Fix it in 30 seconds

To sort this out, you just need to point your repository’s remotes to the new address.

Bash

# Check how you have it right now
git remote -v

# Point it to the new host
git remote set-url origin git@ssh.bitbucket.org:your-account/your-repo.git

And test it like this:

Bash

ssh -Tv git@ssh.bitbucket.org

If it spits back the official welcome greeting confirming you’re authenticated, you’re officially out of the blast radius.

Don’t push this to Friday at 6:00 PM. Hop onto your build runners, audit your staging boxes, double-check your workstation, and get your SSH sorted today. Having gray hair in this line of work is about anticipating the fire, not spending your evening hauling buckets of water to put it out.

Happy clean coding, and may the SSH demons show you mercy! 🤘🔥