Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,297,154
Community Members
 
Community Events
165
Community Groups

App password being ignored on new machine

Edited

I created an app password for my Bitbucket profile a few months ago, and have been using it to access (clone, branch, push, & pull) various repositories on different remote machines since then.

Recently I've been having issues on one machine. Following the instructions in this thread:

https://community.atlassian.com/t5/Bitbucket-questions/How-do-I-use-the-new-app-password-for-command-line-Git/qaq-p/1955078

... I switched to using the app password with the following command:

> git remote set-url origin https://<my Bitbucket user name>:<my app password>@bitbucket.org/<repo owner's user name>/<repo name>.git

This doesn't report any problems, but when next I try communicating with the remote server, I get the same error message I'd see if I never added the app password at all:

 > git push

remote: Bitbucket Cloud recently stopped supporting account passwords for Git authentication.

remote: See our community post for more details: https://atlassian.community/t5/x/x/ba-p/1948231

remote: App passwords are recommended for most use cases and can be created in your Personal settings:

remote: https://bitbucket.org/account/settings/app-passwords/

fatal: Authentication failed for 'https://bitbucket.org/<repo owner's user name>/<repo name>.git/'

 

2 answers

2 accepted

0 votes
Answer accepted

Found my problem, and it's stupid. I'd set the app password *twice*, and screen captured it each time, saving the screencaps in different locations. I then was using the *old* app password on the machine in question, and didn't realize it.

I just found the new app password, and used it in the "git remote set-url origin" command. This time it worked.

So I'll close this report. The only thing I'd like is for the system to report that the app password being used was *incorrect*, rather than imply that I wasn't using one at all.

0 votes
Answer accepted
Patrik S Atlassian Team Jun 02, 2022

Hello @beany_kelly ,

Thank you for reaching out to Atlassian Community!

The command you have used to switch to app password is specific when cloning from your personal repository, as you are using your username as the workspace name. By default when you create a bitbucket account, a personal workspace is created with the same name as your Bitbucket username, and this is why that command was working when cloning from your personal repository.

Having said that, a more generic command, that works for all the cases, including shared workspaces, would be the following : 

git remote set-url origin https://<BITBUCKET USERNAME>:<APP PASSOWORD>@bitbucket.org/<WORKSPACE NAME>/<REPO SLUG>.git

Please note that we are using the WORKSPACE NAME as part of the path in the URL. 

Could you please try using the command above and let us know how it goes? 

Hope that helps! Let us know in case you run into any issues.

Thank you @beany_kelly !

Kind regards,

Patrik S

Hi Patrik. I'm a bit confused by your alternative command, as to my knowledge, the <WORKSPACE NAME> is the same as the <repo owner's user name> (I wasn't using my own workspace, and wasn't using my bitbucket name in there).

To be more specific, the repository is called "<REMOVED>", and it belongs to the user "<REMOVED>": https://bitbucket.org/<WORKSPACE>/<REPOSITORY/src/master/

The command I run is:

git remote set-url origin https://USERNAME:<MY APP PASSOWORD>@bitbucket.org/WORKSPACE/REPOSITORY.git 

 ... and it's not working for me. The name "<REMOVED>" appears in the clone command on that page, so if it's *not* the workspace name, I don't know what is.

Patrik S Atlassian Team Jun 02, 2022

Hello @beany_kelly ,

I have edited your previous answer to remove the personal information such as workspace and repository names.

Back to your question, the workspace name is the same as  <repo owner's user name>  for personal workspaces by default. But in Bitbucket Cloud you have the option to change the workspace name to a name different than your Bitbucket username. You also have the option to create additional workspaces, other than your personal,that are not attached to your account, and are considered shared workspaces, owned by all the users that are in the Administrators group. This is the reason I said the correct generic URL would be  : 

ttps://<BITBUCKET USERNAME>:<APP PASSOWORD>@bitbucket.org/<WORKSPACE NAME>/<REPO SLUG>.git

As you are cloning from someone else's personal repo, the URL you have used seems to be correct. Since you are still facing the error, my suggestion, in this case, would be

  • Check if the app password you used has not any typos or does not have the required permissions. You can try creating a new App password and try again.
  • Verify if your git credentials are not cached in your system, and it's using your account's password: 
    • Windows : Go to  Credential Manager > Windows Credentials > Delete any entries related to Bitbucket.org
    • MacOS : Go to KeyChain Access > Search for bitbucket > Delete the entries related to Bitbucket

If the above does not work, could you please run the git push including verbose logs, and share here the result? The command would be like the below : 

GIT_TRACE_PACKET=1 GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push

 When sharing the full output, please make sure to sanitize any personal information such as passwords/login/username.

Thank you, @beany_kelly !

Kind regards,

Patrik S

Hi @Patrik S . Thanks for the quick response, and for explaining the possible distinction between the user name and the workspace name (which doesn't apply here).

Taking your second suggestion first, the machine I'm using this on is a remote supercomputer running a flavor of Linux, so the Windows & MacOS instructions for searching for Git credentials don't apply. I tried following the guidance here:[  https://stackoverflow.com/questions/44246876/how-to-remove-cached-credentials-from-git ], but unless they're somewhere nonstandard (i.e. not in my $HOME on this machine), I didn't have any credentials cached (i.e. there's no .git-credentials there).

For your first suggestion, I'm not sure what you mean by "Check if the app password [...] does not have the required permissions". I have one app password set up on Bitbucket, and I'm using it for accessing repositories owned by me and other collaborators. If I have commit privileges to someone else's repository, can't I use the same app password I'm using for my own?

Patrik S Atlassian Team Jun 03, 2022

Hello @beany_kelly .

For the "Check if the app password [...] does not have the required permissions" I meant to check if the app password you are using had the repository:read and repository:write scopes checked when you created it. Since you mentioned you have used the exact same app password to push to other repos, this should not be the issue.

As you are using Linux and you found no evidence of cache in your environment, we'd be interested in the verbose logs from git to investigate further. Could you please try pushing to the repo using the command below and share with us the full output? 

GIT_TRACE_PACKET=1 GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push

The verbose logs will include your authentication credentials base64 encoded in a header called Authorization. Please make sure to sanitize this information and any other personal information (such as username/repository/workspace) from the logs before pasting here.

Also, we'd like you to run the following commands in that machine to check whether there's any cache configured in your git environment : 

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

Let me know in case you have any questions.

Thank you, @beany_kelly !

Kind regards,

Patrik S 

Hi Patrik. Thanks for explaining the permissions comment. Yes, I definitely had it set for read & write. It would be nice to be able to verify things like this after the fact too, but you can't really tell anything about existing app passwords once they're set (at least from the BB site).

I ran the three "git config" commands you mentioned, and each returned nothing at all, which I assume means there's no cache on that machine at any level?

Here's the result of that "GIT_TRACE_PACKET=1 GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push", suitable sanitized (as far as I can see):

------------------------------

15:51:33.381891 git.c:447 trace: built-in: git push
15:51:33.382838 run-command.c:667 trace: run_command: GIT_DIR=.git git remote-https origin https://USERNAME:<MY APP PASSOWORD>@bitbucket.org/WORKSPACE/REPOSITORY.git
15:51:33.387598 git.c:733 trace: exec: git-remote-https origin https://USERNAME:<MY APP PASSOWORD>@bitbucket.org/WORKSPACE/REPOSITORY.git
15:51:33.387640 run-command.c:667 trace: run_command: git-remote-https https://USERNAME:<MY APP PASSOWORD>@bitbucket.org/WORKSPACE/REPOSITORY.git
15:51:33.398697 http.c:756 == Info: Couldn't find host bitbucket.org in the .netrc file; using defaults
15:51:33.400419 http.c:756 == Info: Trying 104.192.141.1...
15:51:33.400439 http.c:756 == Info: TCP_NODELAY set
15:51:33.437718 http.c:756 == Info: Connected to bitbucket.org (104.192.141.1) port 443 (#0)
15:51:33.438632 http.c:756 == Info: ALPN, offering http/1.1
15:51:33.444057 http.c:756 == Info: successfully set certificate verify locations:
15:51:33.444071 http.c:756 == Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
15:51:33.444249 http.c:756 == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
15:51:33.600469 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
15:51:33.600547 http.c:756 == Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
15:51:33.600716 http.c:756 == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
15:51:33.701528 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
15:51:33.701771 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, [no content] (0):
15:51:33.701777 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
15:51:33.701789 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, [no content] (0):
15:51:33.701799 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, Certificate (11):
15:51:33.703098 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, [no content] (0):
15:51:33.703107 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, CERT verify (15):
15:51:33.703237 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, [no content] (0):
15:51:33.703249 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, Finished (20):
15:51:33.703299 http.c:756 == Info: TLSv1.3 (OUT), TLS handshake, [no content] (0):
15:51:33.703305 http.c:756 == Info: TLSv1.3 (OUT), TLS handshake, Finished (20):
15:51:33.703349 http.c:756 == Info: SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
15:51:33.703354 http.c:756 == Info: ALPN, server accepted to use http/1.1
15:51:33.703362 http.c:756 == Info: Server certificate:
15:51:33.703379 http.c:756 == Info: subject: jurisdictionC=US; jurisdictionST=Delaware; businessCategory=Private Organization; serialNumber=3928449; C=US; ST=California; L=San Francisco; O=Atlassian, Inc.; CN=bitbucket.org
15:51:33.703385 http.c:756 == Info: start date: Apr 27 00:00:00 2022 GMT
15:51:33.703390 http.c:756 == Info: expire date: May 27 23:59:59 2023 GMT
15:51:33.703399 http.c:756 == Info: subjectAltName: host "bitbucket.org" matched cert's "bitbucket.org"
15:51:33.703407 http.c:756 == Info: issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
15:51:33.703410 http.c:756 == Info: SSL certificate verify ok.
15:51:33.703437 http.c:756 == Info: TLSv1.3 (OUT), TLS app data, [no content] (0):
15:51:33.703454 http.c:703 => Send header, 0000000222 bytes (0x000000de)
15:51:33.703460 http.c:715 => Send header: GET /WORKSPACE/REPOSITORY.git/info/refs?service=git-receive-pack HTTP/1.1
15:51:33.703462 http.c:715 => Send header: Host: bitbucket.org
15:51:33.703465 http.c:715 => Send header: User-Agent: git/2.31.1
15:51:33.703479 http.c:715 => Send header: Accept: */*
15:51:33.703482 http.c:715 => Send header: Accept-Encoding: deflate, gzip, br
15:51:33.703484 http.c:715 => Send header: Accept-Language: en-US, *;q=0.9
15:51:33.703487 http.c:715 => Send header: Pragma: no-cache
15:51:33.703489 http.c:715 => Send header:
15:51:33.802872 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, [no content] (0):
15:51:33.802972 http.c:756 == Info: TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
15:51:33.803035 http.c:756 == Info: TLSv1.3 (IN), TLS app data, [no content] (0):
15:51:33.803055 http.c:703 <= Recv header, 0000000027 bytes (0x0000001b)
15:51:33.803061 http.c:715 <= Recv header: HTTP/1.1 401 Unauthorized
15:51:33.803066 http.c:703 <= Recv header, 0000000052 bytes (0x00000034)
15:51:33.803069 http.c:715 <= Recv header: WWW-Authenticate: Basic realm="Bitbucket.org HTTP"
15:51:33.803072 http.c:703 <= Recv header, 0000000026 bytes (0x0000001a)
15:51:33.803075 http.c:715 <= Recv header: Content-Type: text/plain
15:51:33.803078 http.c:703 <= Recv header, 0000000037 bytes (0x00000025)
15:51:33.803081 http.c:715 <= Recv header: Date: Fri, 03 Jun 2022 21:51:32 GMT
15:51:33.803084 http.c:703 <= Recv header, 0000000024 bytes (0x00000018)
15:51:33.803086 http.c:715 <= Recv header: Connection: Keep-Alive
15:51:33.803090 http.c:703 <= Recv header, 0000000020 bytes (0x00000014)
15:51:33.803093 http.c:715 <= Recv header: Content-Length: 12
15:51:33.803098 http.c:703 <= Recv header, 0000000002 bytes (0x00000002)
15:51:33.803100 http.c:715 <= Recv header:
15:51:33.803103 http.c:756 == Info: Ignoring the response-body
15:51:33.803119 http.c:756 == Info: Connection #0 to host bitbucket.org left intact
15:51:33.803126 http.c:756 == Info: Issue another request to this URL: 'https://USERNAME:<MY APP PASSOWORD>@bitbucket.org/WORKSPACE/REPOSITORY.git/info/refs?service=git-receive-pack'
15:51:33.803191 http.c:756 == Info: Couldn't find host bitbucket.org in the .netrc file; using defaults
15:51:33.803201 http.c:756 == Info: Found bundle for host bitbucket.org: 0x561fbb170c40 [can pipeline]
15:51:33.803208 http.c:756 == Info: Re-using existing connection! (#0) with host bitbucket.org
15:51:33.803214 http.c:756 == Info: Connected to bitbucket.org (104.192.141.1) port 443 (#0)
15:51:33.803224 http.c:756 == Info: Server auth using Basic with user 'USERNAME'
15:51:33.803241 http.c:756 == Info: TLSv1.3 (OUT), TLS app data, [no content] (0):
15:51:33.803278 http.c:703 => Send header, 0000000289 bytes (0x00000121)
15:51:33.803283 http.c:715 => Send header: GET /WORKSPACE/REPOSITORY.git/info/refs?service=git-receive-pack HTTP/1.1
15:51:33.803285 http.c:715 => Send header: Host: bitbucket.org
15:51:33.803288 http.c:715 => Send header: Authorization: Basic <redacted>
15:51:33.803291 http.c:715 => Send header: User-Agent: git/2.31.1
15:51:33.803294 http.c:715 => Send header: Accept: */*
15:51:33.803296 http.c:715 => Send header: Accept-Encoding: deflate, gzip, br
15:51:33.803299 http.c:715 => Send header: Accept-Language: en-US, *;q=0.9
15:51:33.803302 http.c:715 => Send header: Pragma: no-cache
15:51:33.803304 http.c:715 => Send header:
15:51:33.932284 http.c:756 == Info: TLSv1.3 (IN), TLS app data, [no content] (0):
15:51:33.932335 http.c:703 <= Recv header, 0000000027 bytes (0x0000001b)
15:51:33.932342 http.c:715 <= Recv header: HTTP/1.1 401 Unauthorized
15:51:33.932348 http.c:756 == Info: Authentication problem. Ignoring this.
15:51:33.932351 http.c:703 <= Recv header, 0000000052 bytes (0x00000034)
15:51:33.932370 http.c:715 <= Recv header: Www-Authenticate: Basic realm="Bitbucket.org HTTP"
15:51:33.932373 http.c:703 <= Recv header, 0000000025 bytes (0x00000019)
15:51:33.932376 http.c:715 <= Recv header: Cache-Control: no-cache
15:51:33.932379 http.c:703 <= Recv header, 0000000041 bytes (0x00000029)
15:51:33.932382 http.c:715 <= Recv header: Content-Type: text/plain; charset=utf-8
15:51:33.932384 http.c:703 <= Recv header, 0000000032 bytes (0x00000020)
15:51:33.932387 http.c:715 <= Recv header: X-B3-Traceid: efa2f598da545629
15:51:33.932390 http.c:703 <= Recv header, 0000000073 bytes (0x00000049)
15:51:33.932393 http.c:715 <= Recv header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
15:51:33.932396 http.c:703 <= Recv header, 0000000037 bytes (0x00000025)
15:51:33.932398 http.c:715 <= Recv header: Date: Fri, 03 Jun 2022 21:51:33 GMT
15:51:33.932401 http.c:703 <= Recv header, 0000000024 bytes (0x00000018)
15:51:33.932403 http.c:715 <= Recv header: X-Server: 44bc567284f5
15:51:33.932406 http.c:703 <= Recv header, 0000000033 bytes (0x00000021)
15:51:33.932408 http.c:715 <= Recv header: X-Content-Type-Options: nosniff
15:51:33.932411 http.c:703 <= Recv header, 0000000019 bytes (0x00000013)
15:51:33.932414 http.c:715 <= Recv header: Connection: close
15:51:33.932416 http.c:703 <= Recv header, 0000000023 bytes (0x00000017)
15:51:33.932419 http.c:715 <= Recv header: X-Version: aa9156de2f
15:51:33.932423 http.c:703 <= Recv header, 0000000021 bytes (0x00000015)
15:51:33.932425 http.c:715 <= Recv header: Content-Length: 324
15:51:33.932428 http.c:703 <= Recv header, 0000000002 bytes (0x00000002)
15:51:33.932431 http.c:715 <= Recv header:
15:51:33.932469 http.c:756 == Info: Closing connection 0
15:51:33.932482 http.c:756 == Info: TLSv1.3 (OUT), TLS alert, [no content] (0):
15:51:33.932509 http.c:756 == Info: TLSv1.3 (OUT), TLS alert, close notify (256):
remote: Bitbucket Cloud recently stopped supporting account passwords for Git authentication.
remote: See our community post for more details: https://atlassian.community/t5/x/x/ba-p/1948231
remote: App passwords are recommended for most use cases and can be created in your Personal settings:
remote: https://bitbucket.org/account/settings/app-passwords/
fatal: Authentication failed for 'https://bitbucket.org/beany_kelly/gr_codes.git/'

Patrik S Atlassian Team Jun 07, 2022

Hello @beany_kelly ,

Thank you for sharing the output.

From the verbose logs I did not identify any attempt to use credentials in the cache. Is this happening only on one machine? Would it be possible for you to try using the same clone command with the same credentials in a different machine/network and check if it works?

Kind regards,

Patrik S

Yes it works on other machines, but I just realized why, and it's my own stupidity. See main reply below.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS
Community showcase
Published in Bitbucket

Git push size limits are coming to Bitbucket Cloud starting April 4th, 2022

Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is over 3.5 GB. If you do attempt to complete a push that is over 3.5 GB, it will fail...

2,207 views 2 9
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you