Reputation:
When cloning a git repository sitting up in Azure Repos into my local machine clone succeeds but I get a line that says:
Logon failed, use ctrl+c to cancel basic credential prompt
Not sure what this is referring to, any ideas?
I'm using PAT token to authenticate my clone, command is:
git clone https://*************PAT*************@dev.azure.com/orgname/projectname/_git/reponame
Upvotes: 118
Views: 133602
Reputation: 371
Our company has 2 domains that we access DevOps:
https://vso[companyname].visualstudio.com
and
https://dev.azure.com/vso[companyname]
In the repos .gitsubmodule file I changed the URL from one to the other, and the build magically started working.
Upvotes: 1
Reputation: 51
If you are still getting this error for BitBucket & Visual Studio 2019 then please use app password instead of your regular BitBucket login password as of Mar 1 2022 BitBucket stopped using regular password for API based authentication. See reference
Upvotes: 0
Reputation: 1
You can try 3 things to resolve this issue
Upvotes: 0
Reputation: 4262
It happens if the git is not updated to the latest version.
Please update the git and you are good to go.
To update the git, just follow the below command depending on the type of OS you are using:
windows: git update-git-for-windows
Linux/Unix: git update
or follow the below link to get the latest copy of the git client for your OS
Upvotes: 306
Reputation: 755
You just need to update your git. open terminal and type IN WINDOWS
git update-git-for-windows
IN OTHER
git update
Upvotes: 16
Reputation: 11
I've encountered a similar issue when using git repos on my local machine which are cloned from an Azure DevOps repository.
The initial clone works, I can pull/push without issue until I have to re-authenticate with azuread/adfs as the session eventually expires. Git will correctly prompt with the azure login page, and I can successfully authenticate against our tenancy, but Git will error with the basic credential prompt and "Logon failed, use ctrl+c to cancel basic credential prompt" appearing.
The only way I have found to get around this is to login to Azure DevOps via the browser (where my session will have also expired), then do the authentication with git again, which somehow allows it to work.
Upvotes: 1
Reputation: 703
If you are using github repositories, you might need to check that you have not removed the rights of Azure Pipelines in your github Applications settings:
Upvotes: 0
Reputation: 3361
Git http.extraheader & bearer
Manual 's answer helped put me on the right track.
YAML style Pipelines can use the preset variable System.AccessToken. After examining the formal 'Checkout ...' step at the beginning of the Pipeline I found this step to work in my script:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: 'git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --depth 1 https://[email protected]/my-org/my-proj/_git/my-repo'
Note that Azure DevOps job authorization scope may affect this
Upvotes: 2
Reputation: 525
I think that the problem is that you did not allowed your Agent job to acces the Auth token.
Try to check this option for the agent job:
Upvotes: 2
Reputation: 1
Just need to create the credentials from the azure. click on clone->click git credentials-> it will create the user name and password . use this password in jenkins job. It will work
Upvotes: 0
Reputation: 76874
It looks like in this case you actually have two sets of credentials that are in use, and Git has tried one and failed, and fallen back to the other one. This prompt comes up when the credential manager is invoked on Windows in case a prompt is displayed and you need to enter some credentials.
When you put a PAT in the URL like in this case, you need to put the PAT as the password. That means you need to specify a username, so your URL should start with something like https://username:[email protected]/
. It isn't clear from your post whether you have the username:
portion, so if you don't be sure to add one (it can be anything in this case; token
and your username are common).
If you don't have a URL of that form, your PAT isn't being used, and you're likely falling back to whatever is in your credential manager, which is correct. Otherwise, it's possible that Git is preferring something in your credential manager which isn't correct, and falling back to something that is. Either way, you should inspect the credentials in Windows Credential Manager and delete any that are incorrect.
Upvotes: 2