Push error points to an incorrect account

If the remote points to scottyhuff2 and SSH authentication fails, first correct the remote to scottyhuff and fix the SSH key/configuration. Then retry the push. If the error still references scottyhuff2, it would be worth contacting Atlassian Support to check for a legacy workspace or entitlement association. 

git remote -v returns:

origin git@bitbucket-gigprompter:scottyhuff/gigprompter.git (fetch)
origin git@bitbucket-gigprompter:scottyhuff/gigprompter.git (push)

And it will authenticate scottyhuff but when I did a 'git push -u origin main', the response was:

******************************************************************************** [ALERT] Your push failed because the account 'scottyhuff2' has exceeded its [ALERT] user limit and this repository is restricted to read-only access. [ALERT] Change your plan to restore write access: [ALERT] https://bitbucket.org/scottyhuff/workspace/settings/plans ******************************************************************************** fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

It's like it thinks there are two workspaces or repositories but when I look at my bitbucket settings, there is only one workspace (scottyhuff) and one repository.

And I'm on the free version so there is no Atlassian Support other than this discussion group. Tough to think about paying for something that's already broken.

You can still raise support ticket on free plan, support can still help. Or guide you.

As the remote points to scottyhuff, it is more on bitbucket server-side. I would still raise support ticket. 

Hi Scotty,

There's a detail in your own paste that I don't think anyone has picked up yet. Your remote reads git@bitbucket-gigprompter:scottyhuff/gigprompter.git, and bitbucket-gigprompter isn't a Bitbucket hostname at all; it's a Host alias out of your ~/.ssh/config. That means the key your push offers is whichever IdentityFile that particular block names, and it needn't be the same key you tested with.

The distinction matters because Bitbucket works out who you are from the key you present rather than from the path written into the remote. A remote pointing at scottyhuff will still be evaluated as whatever account the offered key belongs to. In most cases that's how you'd end up staring at an error naming scottyhuff2 while your remote, your workspace and your user list all say scottyhuff.

What I'd do is test the alias itself rather than the host, so run ssh -Tv bitbucket-gigprompter and read which identity file it offers and which one the server accepts. Atlassian's documented check is ssh -T git@bitbucket.org, and I'd usually expect that to pass regardless, since it walks a different path than your push does.

Does the alias resolve to the key you were expecting?

Great observation @Gabriela - LeanZero 

Thanks all. But oddly enough, I tried the push again without changing anything and it worked. Must've been a timing/propogation thing? Who knows. It's working though. Onward through the fog!