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; } } }

BitBucket Accepts Invalid SSH Key for Account

mdgmichael

Hi! This issue started occurring for me within the last 1–2 weeks. I use BitBucket with two accounts:

Personal
Username: kaelri
SSH Key: ~/.ssh/id_rsa (default)
Work
Username: mdgmichael
SSH Key: ~/.ssh/mdgmichael

When I try to `git fetch/pull/push` to a repo under my work account, I get a “forbidden” error. Using `ssh mdgmichael@bitbucket.org -v`, I can see what's happening: my SSH agent is offering my default key first, and BitBucket is accepting that key, even though it’s not valid for that account. In other words, I’m logging in with my work account, but it’s authenticating me as my personal account, and then (naturally) refusing access to my work repos.

Here's a log excerpt:

$ ssh mdgmichael@bitbucket.org -v

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/kaelri/.ssh/config
…
debug1: Authenticating to bitbucket.org:22 as 'mdgmichael'
…

debug1: Will attempt key: /Users/kaelri/.ssh/id_rsa RSA SHA256:… explicit agent
debug1: Will attempt key: /Users/kaelri/.ssh/mdgmichael RSA SHA256:… explicit agent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/kaelri/.ssh/id_rsa RSA SHA256:… explicit agent
debug1: Server accepts key: /Users/kaelri/.ssh/id_rsa RSA SHA256:… explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to bitbucket.org ([18.205.93.0]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
PTY allocation request failed on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
logged in as kaelri

I could reverse the order of the offered keys, but presumably I would then have the same problem in reverse when I tried pulling from my personal repos. I could also get around this by using aliases in my SSH config file, but I’d obviously rather not have to modify the remote URLs for dozens of repos.

In any case, it does not make a lot of sense that BitBucket would accept a key that's not associated with the indicated username. Again, I'm fairly sure this is a recent change in behavior; I've been using these accounts side-by-side for many months without an issue like this.

Any ideas? Obviously it would be great if this could be fixed at the source. Short of that, is there any way (other than aliases) that I can stop my SSH agent from offering the wrong key?

Accepted answers

mdgmichael

An update: I found a workaround using "Match" statements in my SSH config file:

Host bitbucket.org
    HostName bitbucket.org
    Match user kaelri
        IdentityFile ~/.ssh/id_rsa
    Match user mdgmichael
        IdentityFile ~/.ssh/mdgmichael

I still suspect this is something that should be reviewed or addressed by the BitBucket team. But hopefully this solution will work for others in my position.

All comments

mdgmichael

An update: I found a workaround using "Match" statements in my SSH config file:

Host bitbucket.org
    HostName bitbucket.org
    Match user kaelri
        IdentityFile ~/.ssh/id_rsa
    Match user mdgmichael
        IdentityFile ~/.ssh/mdgmichael

I still suspect this is something that should be reviewed or addressed by the BitBucket team. But hopefully this solution will work for others in my position.

Mateusz Sidorski

oh lord, THANK you.

Adambean

That's a good workaround @mdgmichael, I've had exactly the same issue lately with all the working at home going on.

Unfortunately this doesn't work for Pageant mounted keys. BitBucket will still just accept the first key attempted. This needs a resolution from BitBucket.

It seems silly that this problem came up at all. The remote URLs for our repository contain our BitBucket username, so it's just common sense that public key offerings should be accepted in the basis of whether they're attached to the username specified in the remote URL, not just whether the SSH key has been added at all.

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