SSH host key rotated on 2026/06/02 ?

[Ian Ling]

The SSH host key for bitbucket.org appears to have changed suddenly. I don't see any official communication about this.

[Ben]

Hi @Ian Ling @Ajay _view26_ @Todd Samuelson @Marcel 

What happened

Between 2026-06-02 19:38 UTC and 20:09 UTC, bitbucket.org's SSH service temporarily presented our previous host key used prior to Bitbucket’s 2023 Host Key Rotation. If, during that window, you removed your saved bitbucket.org entry and re-accepted the new key, your known_hosts may now contain the wrong (old) key.

We've corrected the service, so it's once again presenting the correct host keys. As a result you may now see this error again:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ... Offending ... key in /home/you/.ssh/known_hosts:42

This is expected, and the fix is to remove the stale entry and let your client re-learn the correct key.

Was this a security incident?

No. Despite the warning, no security incident has actually occurred. This was triggered by a configuration update which inadvertently caused Bitbucket to serve SSH traffic using the previous, pre-2023-rotation key.

If you received a REMOTE HOST IDENTIFICATION HAS CHANGED error in this window, your connection was still private. If you have any concerns, refer to the Fingerprints section below.

Fix

1. Remove the old/incorrect bitbucket.org entry from known_hosts:

macOS / Linux / Git Bash / WSL:

ssh-keygen -R bitbucket.org

If you connect via the altssh endpoint (port 443), also run:

ssh-keygen -R altssh.bitbucket.org

Windows (PowerShell, OpenSSH):

ssh-keygen -R bitbucket.org

The error message often prints the exact file and line number (e.g. known_hosts:42). You can also open that file and delete the bitbucket.org line manually.

2. Reconnect and VERIFY the fingerprint before accepting. Do not blindly type yes.

ssh -T git@bitbucket.org

You'll be prompted with a fingerprint. Confirm it matches one of Bitbucket's official published host key fingerprints (link below) before accepting. This step is what protects you - accepting without checking is what led to the wrong key being saved in the first place.

3. Confirm git works:

git fetch

Important

• Always verify the fingerprint against Bitbucket's official documentation. A genuine MITM looks identical to this benign error, so the fingerprint check is the only safe way to tell them apart.

• You only need to do this once per machine that re-accepted the key during the incident window.

• If you did not touch your known_hosts during the incident, you likely don't need to do anything - your saved key is already correct.

Official Fingerprints

Verify against Bitbucket's published SSH host key fingerprints here: https://support.atlassian.com/bitbucket-cloud/docs/configure-ssh-and-two-step-verification

Bitbucket’s current RSA key fingerprint:

SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E

During the incident, Bitbucket.org’s previous RSA key was incorrectly showing:

SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A

[Scott Ledbetter]

> Was this a security incident?

> No. Despite the warning, no security incident has actually occurred.

Respectfully, this was a security event. It's plain to see in context:

> If, during that window, you removed your saved bitbucket.org entry and re-accepted the new key, your known_hosts may now contain the wrong (old) key.

This was a retired host key that Atlassian rotated away from after the key material was included in a third party breach dataset, albeit encrypted.

Customers may have assumed this was normal key activity due to the upcoming SSH migration. Without a broader announcement or status page notice, some customers may now trust a retired Bitbucket host key that Atlassian previously moved away from for security reasons.

If that private key material were ever recovered by an attacker with a suitable network position, those customers could be exposed to server-impersonation / MITM risk.

The issue is that Atlassian created a customer facing trust-anchor event and has not communicated it through an appropriate public incident channel.

[Ajay _view26_]

Hi @Ian Ling 

Welcome to the community!

What you're seeing is almost certainly related to Atlassian's recently announced SSH migration rather than an unannounced key rotation.

About three weeks ago, Atlassian published an article saying Bitbucket Cloud is moving SSH traffic from bitbucket.org to a new hostname, ssh.bitbucket.org. The first time clients connect to that new endpoint, they'll get a host key verification prompt, which looks exactly like what you're describing.

[Todd Samuelson]

We had the same issue also for a short time, but I tried to use it again, just now, without doing anything else and it seems to have been resolved itself.

[Marcel]

I have the same issue so I'll follow this topic.