Introduction

fatal: Invalid credentials means Bitbucket rejected the identity Git presented during push. The fix is usually not in your commits or branch state. It is in the authentication method, the stored credential cache, or the username and token pair being sent to Bitbucket.

Start by Checking How the Remote Authenticates

The first thing to inspect is the remote URL. If it starts with https://, Git is using HTTPS authentication. If it starts with [email protected]:, it is using SSH.

git remote -v

That distinction matters because the troubleshooting path is different. For HTTPS, the usual causes are stale cached credentials, the wrong username, or using a password where Bitbucket expects a token. For SSH, the problem is normally keys, agent setup, or repository access, and the error message is usually different.

Fixing HTTPS Authentication

Bitbucket Cloud no longer accepts your normal account password for Git pushes over HTTPS. As of March 11, 2026, Atlassian recommends SSH for interactive Git use and is transitioning HTTPS Git authentication toward API tokens, with app passwords scheduled to stop working after June 9, 2026.

A clean HTTPS fix looks like this:

git remote set-url origin https://[email protected]/workspace/repository.git
git push

When Git prompts for a password, paste the API token. If your workspace is still using app passwords today, that may continue to work temporarily, but it is safer to move to the current token guidance now rather than wait for the June 9, 2026 cutoff.

Also verify the username. Atlassian notes that the token name or your email address is not the same thing as the Bitbucket username used by older authentication flows. A mismatched username plus a valid token is still rejected.

Clear Cached Credentials When the Secret Changed

If you recently rotated the token, enabled two-step verification, or switched from password auth, your machine may still be sending an old credential from the OS credential store.

On Linux, the exact cleanup step depends on which helper you use. You can at least confirm the helper first:

git config --global credential.helper
git config --system credential.helper

If you are using the plain-text credential store, remove the Bitbucket entry and try again:

sed -i.bak '/bitbucket.org/d' ~/.git-credentials
git push

If you are using a desktop keyring helper, clear the Bitbucket entry in that keyring tool instead. The important part is to remove the stale secret so Git is forced to ask again.

Switching to SSH

For day-to-day interactive work, SSH is often simpler because it avoids repeated token prompts once the key is installed correctly.

1ssh-keygen -t ed25519 -C "[email protected]"
2cat ~/.ssh/id_ed25519.pub
3ssh -T [email protected]
4git remote set-url origin [email protected]:workspace/repository.git
5git push -u origin HEAD

After you add the public key to Bitbucket, ssh -T should confirm that authentication works. If it does, pushes will stop depending on HTTPS credentials entirely.

Common Pitfalls

• Using the Bitbucket account password for HTTPS Git operations instead of a supported token.
• Reusing an old token that is still cached in the credential helper or desktop keychain.
• Typing the email address or token label where Bitbucket expects the actual Bitbucket username or the documented token username.
• Mixing SSH and HTTPS advice. Changing tokens does nothing if the remote is already using [email protected]:.
• Creating a token without repository write permission, which causes push to fail even if authentication succeeds.

Summary

• 'fatal: Invalid credentials is usually an authentication-method problem, not a Git history problem.'
• Check whether your remote uses HTTPS or SSH before changing anything.
• For Bitbucket Cloud HTTPS pushes, use the current token-based guidance rather than the account password.
• Clear stale cached credentials so Git stops reusing an old secret.
• For interactive Git work, SSH is often the cleanest long-term fix.