Authentication failed issue

trains78 commented 5 months ago

The problem

Github Dekstop updated to 3.3.15 and is now asking for credentials to fetch everytime. We use Azure DevOps repo with Personal access tokens. Anyone on our team with 3.3.14 is not having this issue. We receive the following error everytime even when updating the access token on Azure.

Release version

3.3.15

Operating system

Windows 11

Steps to reproduce the behavior

Fetch any repo from private repo on Azure Devops

Log files

2024-05-09.desktop.production.log

Screenshots

Additional context

Have about 20 members on the team and anyone who has version 3.3.15 and up of Github Desktop is having this issue. Anyone with 3.3.14 is not.

tidy-dev commented 5 months ago

@trains78 Can you please update to the latest (being 3.3.17) and let us know if you are still having issues?

steveward commented 5 months ago

Thanks for the issue @trains78. This should be fixed in the latest release of GitHub Desktop.

Could you please try holding down Alt on your keyboard and then clicking on the Check for updates button (it'll change its text to Ensure latest version)? Once the new version has been installed please let us know if you run into any issues.

trains78 commented 5 months ago

Thank you for the quick response. We are still having this issue with one of our developers after taking the suggested steps

![image](https://github.com/desktop/desktop/assets/169380912/71903d7e-f633-49be 2024-05-09.desktop.production (1).log -90d8-c4fc88a04930)

tidy-dev commented 5 months ago

Just to make sure I understand: You have 19 devs that can access the same repositories that is failing for the one on 3.3.17?

If so could you make sure that that user is using a valid PAT and try to authenticate again.

poblish commented 5 months ago

I have started to see this today with 3.3.17 when trying to push to a self-hosted Gogs repo on localhost. I've never had any problems doing that until today (multiple years of use, many times per day). I've had to switch to doing Open in Terminal and pushing from there. No auth or PAT is involved here. Using macOS 14.4.1 (23E224)

By contrast, pushing to our private Github repos is all fine.

Looking at the release history, I can't be sure whether I was using 3.3.15 or 3.3.16 before I noticed the upgrade announcement and clicked on it this evening, but I am 100% on 3.3.17 now.

I see this issue has some history, so apologies if I've posted in the wrong place 😊

This might help:

2024-05-09T23:59:16.219Z - info: [ui] askPassHandler: no account found for localhost
2024-05-09T23:59:37.908Z - info: [ui] askPassHandler: user cancelled generic git authentication
2024-05-09T23:59:37.919Z - info: [ui] Executing fetch: git -c credential.helper= fetch --progress --prune --recurse-submodules=on-demand origin (took 21.736s)
2024-05-09T23:59:37.919Z - error: [ui] `git -c credential.helper= fetch --progress --prune --recurse-submodules=on-demand origin` exited with an unexpected code: 128.
stderr:
fatal: Authentication failed for 'http://localhost:3000/aregan/MyRepo.git/'

(The error was parsed as 2: Authentication failed. Some common reasons include:

- You are not logged in to your account: see GitHub Desktop > Settings.
- You may need to log out and log back in to refresh your token.
- You do not have permission to access this repository.
- The repository is archived on GitHub. Check the repository settings to confirm you are still permitted to push commits.
- If you use SSH authentication, check that your key is added to the ssh-agent and associated with your account.
- If you use SSH authentication, ensure the host key verification passes for your repository hosting service.
- If you used username / password authentication, you might need to use a Personal Access Token instead of your account password. Check the documentation of your repository hosting service.)
2024-05-09T23:59:41.986Z - info: [ui] askPassHandler: no account found for localhost

JoseIvanHernandez commented 5 months ago

Commit

herobrinePerssion commented 5 months ago

Is there anyone can fix this ?

trains78 commented 5 months ago

Just to make sure I understand: You have 19 devs that can access the same repositories that is failing for the one on 3.3.17?

If so could you make sure that that user is using a valid PAT and try to authenticate again.

At least one. I haven’t had all update just yet. The ones that have greater than 3.3.14 have this issue. Created new PAT. Uninstalled / Reinstalled. Cloned repo again. Issue remains. I was able to follow the steps above and do not have an issue. But the folks that were seeing it originally still do after Ensure latest update.

niik commented 5 months ago

@poblish I see that you're using repositories over unencrypted http, we fixed a regression related to this scenario in #18589 and we've released it to our beta channel. Could you please try installing our beta version from https://desktop.github.com/beta/ and try again?

@herobrinePerssion Could you please open a new issue and provide some more details and a log file? Before doing so please make sure you've also updated to the latest beta version from https://desktop.github.com/beta/.

@trains78 We fixed a few bugs in rapid succession in 3.3.16 and 3.3.17. If the issue persist for users on 3.3.17 please have one of them open a new issue and include a log file so that we can investigate. Thanks!

RoHeck commented 5 months ago

I have the same problem (with Azure DevOps). Is there a way to install/download an older version of github-desktop?

niik commented 5 months ago

@RoHeck What version of GitHub Desktop are you on right now? If it's 3.3.17 could you please open a new issue and upload a log file from GitHub Desktop so that I could get some more information about this issue? To access the log files go to the file menu in GitHub Desktop and select Help > Show Logs in Finder (macOS) or Explorer (Windows).

The log files are created daily -- please upload a log file as an attachment from a day where you experienced the issue. Thanks!

poblish commented 5 months ago

@niik Just downloaded Version 3.3.18-beta1 (x64) and the situation is unchanged there.

sergiou87 commented 5 months ago

@poblish could you share the new logs with 3.3.18-beta1, please? 🙏 Thank you!

poblish commented 5 months ago

@poblish could you share the new logs with 3.3.18-beta1, please? 🙏 Thank you!

Sure - this is from performing a Fetch on my repo:

2024-05-10T09:24:52.893Z - info: [ui] Subscribed 'poblish' to Alive channel
2024-05-10T09:24:52.945Z - info: [ui] [AppStore] loading 173 repositories from store
2024-05-10T09:24:52.946Z - info: [ui] [AppStore] found account: poblish (Andrew Regan)
2024-05-10T09:24:53.670Z - info: [ui] launching: 3.3.18-beta1 (Mac OS 14.4.1)
2024-05-10T09:24:56.491Z - info: [ui] askPassHandler: no account found for localhost
2024-05-10T09:24:57.819Z - info: [ui] askPassHandler: user cancelled generic git authentication
2024-05-10T09:24:57.829Z - info: [ui] Executing fetch: git -c credential.helper= fetch --progress --prune --recurse-submodules=on-demand origin (took 1.390s)
2024-05-10T09:24:57.829Z - error: [ui] `git -c credential.helper= fetch --progress --prune --recurse-submodules=on-demand origin` exited with an unexpected code: 128.
stderr:
fatal: Authentication failed for 'http://localhost:3000/aregan/MyRepo.git/'

(The error was parsed as 2: Authentication failed. Some common reasons include:

- You are not logged in to your account: see GitHub Desktop > Settings.
- You may need to log out and log back in to refresh your token.
- You do not have permission to access this repository.
- The repository is archived on GitHub. Check the repository settings to confirm you are still permitted to push commits.
- If you use SSH authentication, check that your key is added to the ssh-agent and associated with your account.
- If you use SSH authentication, ensure the host key verification passes for your repository hosting service.
- If you used username / password authentication, you might need to use a Personal Access Token instead of your account password. Check the documentation of your repository hosting service.)

git version 2.45.0

niik commented 5 months ago

@poblish only looking at the log this looks like a legitimate auth failure. I know you said that there's no username involved there but the host at http://localhost:3000 is requesting credentials and that's why Desktop is asking you.

I'm afraid I'm not familiar with Gogs but could you double check your configuration to see if it is set up to require credentials?

poblish commented 5 months ago

@poblish only looking at the log this looks like a legitimate auth failure. I know you said that there's no username involved there but the host at http://localhost:3000 is requesting credentials and that's why Desktop is asking you.

I'm afraid I'm not familiar with Gogs but could you double check your configuration to see if it is set up to require credentials?

Well, yes, If I run git -c credential.helper= fetch at the CLI, then I am indeed asked for a username, and with the default creds helper (git fetch) I don't need to, but has there been some change in the app - deliberate or not - to circumvent the default helper or git config, or is this just a coincidence and actually a git change? 2 days ago is the last time I know this was definitely working. I wouldn't mind trying an older Desktop build if one is available.

niik commented 5 months ago

@poblish GitHub Desktop has never run the default credential helper so there's no change there. What has happened though is that due to a change in how we store credentials (and an oversight related to servers running on non-standard ports) your instance has "forgotten" the credentials previously stored for your Gogs server. If you enter the correct credentials again Desktop will store them and not ask you for them again.

poblish commented 5 months ago

@poblish GitHub Desktop has never run the default credential helper so there's no change there. What has happened though is that due to a change in how we store credentials (and an oversight related to servers running on non-standard ports) your instance has "forgotten" the credentials previously stored for your Gogs server. If you enter the correct credentials again Desktop will store them and not ask you for them again.

Thanks @niik. I reauthenticated once in Desktop, and everything is now working as before. I'm back on 3.3.17 and all is well.

niik commented 5 months ago

@poblish I'm glad to hear that. Thanks for reporting back and sorry for the inconvenience!

Gabriel-Lacatus commented 5 months ago

Since updating to 3.3.17 today it has complained numerous times about authentication. All for the same repository, in Azure DevOps. In a few cases I click "Fetch", the login popup appears, I generate new Git credentials in DevOps and put them in, then it starts doing stuff and, before finalizing the Fetch, the login popups appears again...

I did notice it started asking for credentials a lot more frequent in the past couple of months compared to before but today it has happened excessively. I don't think credentials expire in a matter of few hours though...

It is also hard to reproduce "on demand" because it happens randomly and there is nothing special that needs to be done other than doing a simple Fetch.

trains78 commented 5 months ago

Since updating to 3.3.17 today it has complained numerous times about authentication. All for the same repository, in Azure DevOps. In a few cases I click "Fetch", the login popup appears, I generate new Git credentials in DevOps and put them in, then it starts doing stuff and, before finalizing the Fetch, the login popups appears again...

I did notice it started asking for credentials a lot more frequent in the past couple of months compared to before but today it has happened excessively. I don't think credentials expire in a matter of few hours though...

It is also hard to reproduce "on demand" because it happens randomly and there is nothing special that needs to be done other than doing a simple Fetch.

This has been our experience as well. When it happens again, I will post the logs.

Gabriel-Lacatus commented 5 months ago

Looking at the logs, I can see that the errors do not come from the repository that I'm doing the Fetch on but for the other repos that are cloned locally.

So you do a Fetch on repo X and apparently it just tries to refresh credentials for repo Y and presents you with the popup. This is what the logs usually show:

error: [ui] `git -c credential.helper= fetch --progress --prune --recurse-submodules=on-demand origin` exited with an unexpected code: 128.
stderr:
fatal: Authentication failed for 'https://dev.azure.com/repo_path_redacted/'

(The error was parsed as 4: Authentication failed. Some common reasons include:
...

tidy-dev commented 5 months ago

So you do a Fetch on repo X and apparently it just tries to refresh credentials for repo Y and presents you with the popup. This is what the logs usually show:

For context, there is a periodic fetch of all repos that happens on an interval and if authentication fails there it will not show you a popup nor error, but it will log the error. Thus, likely that is what you are seeing in your logs.

Gabriel-Lacatus commented 5 months ago

No, I'm afraid this is not currently the case. Just a few seconds ago I clicked Fetch on the open repo and the login popup appeared. I opened the log and I found authentication errors for 3 unrelated repos at around the current timestamp.

I smell something here... I think the periodic refresh that's supposed to work in the background somehow "spills" into the UI and is causing the login popup to appear.

tidy-dev commented 5 months ago

Interesting. Any chance you have submodules?

Gabriel-Lacatus commented 5 months ago

Interesting. Any chance you have submodules?

No, just plain repos from different DevOps tenants.

If it's of any help, I noticed these log entries right after updating: 2024-05-10T07:15:21.747Z - info: [ui] Migrating credentials dev.azure.com/org1/project1 → dev.azure.com 2024-05-10T07:15:21.768Z - info: [ui] Migrating credentials dev.azure.com/org1/project2 → dev.azure.com 2024-05-10T07:15:21.771Z - info: [ui] Migrating credentials dev.azure.com/org2/project3 → dev.azure.com 2024-05-10T07:15:21.772Z - info: [ui] Migrating credentials dev.azure.com/org3/project4 → dev.azure.com 2024-05-10T07:15:21.772Z - info: [ui] Migrating credentials dev.azure.com/org4/project5 → dev.azure.com

Is that expected? Should the URI segment after the arrows be that short (domain only) or should they contain the full org/project structure like the one before the arrow?

tidy-dev commented 5 months ago

Yes. That is expected. GitHub Desktop expects one credential per host. Prior the entire urI was used, with recent changes we have corrected to only user the domain.

Gabriel-Lacatus commented 5 months ago

One per host? Isn't that too little? All the Azure DevOps repos in the world are on the same host: dev.azure.com. That means it only remembers one set of credentials and I have to re-authenticate for each other Organization and Project?

aolszowka commented 5 months ago

I am chiming in to say I am seeing the same behavior.

I would be happy to open a new issue, but I thought I would start here first as this most accurately represents what is going on.

After the first time seeing this (and regenerating the PAT) I see GitHub Desktop save the credentials to the Windows Credential Store, however for reasons not yet understood, after a period of time (less than 1 hour) it appears that these credentials are deleted from the Windows Credential Store and I am then re-prompted.

Looking at the issues it appears that #18594 was also opened and most recently #18606.

@tidy-dev can you link the relevant PR's that you're mentioning above for the changed behavior? I'm having a difficult time finding it.

Based on my understanding of what you're saying here is that this is not going to support multiple repos in Azure DevOps? Looking in my credential store I have various GitHub - dev.azure.com credentials stored for each organization I contribute to. This is no longer supported?

aolszowka commented 5 months ago

I apologize for the double post, but to somewhat answer my own question I believe this is related to a set of several commits from @niik; specifically starting with https://github.com/desktop/desktop/commit/8476019992f0ef034205dcad6e82c56fd2b01ec1

Looking at the logs I can see the migration attempt of the credentials occurring. As mentioned by @Gabriel-Lacatus that's probably going to cause a lot of pain for Azure DevOps users as is mentioned, every repository under the sun that is in Azure DevOps Online is hosted at dev.azure.com. While the username is burnt into the new key name in the store, the whole purpose of having PAT's are that you can have different passwords for the same user account, but tied to a specific organization/project.

Ignoring that for a moment I went ahead and cleared out any existing creds that were in the old format (for some reason the existing ones didn't get removed) my best guess is that some of those in there appear to reference repositories that are no longer accessible (IE the repository was put into Disable Repository state) I wonder if there is some subtle bug here with the conversion if this scenario is encountered? Looking at the logs prior to the conversion I see it attempt to hit some of these legacy repositories. Why keep those on there you ask? Well if you for some reason have to bring them back from Disable Repository State (IE a "soft-delete" operation) its more useful to just maintain them in the list of known repositories.

I'll try to remember to report back in a few days with what ends up happening here.

**EDIT: Spoke too soon, as soon as I hit enter on this comment, the credentials were once again removed. I am going to try removing the "Disabled" repositories and see if I get similar behaviors.

Gabriel-Lacatus commented 5 months ago

Yes, this is becoming unusable. Every Fetch and Pull and Checkout needs new credentials and a roundtrip to Azure DevOps to generate them...

Time to try other Git clients or stick to the VS UI.

aolszowka commented 5 months ago

@Gabriel-Lacatus in GitHub Desktop, do you have any repositories, hosted in Azure DevOps (dev.azure.com) that are no longer accessible? IE they were deleted or disabled? I am trying to see if my working theory here is correct.

I personally had several (at least 10) repositories in such a state, I believe that there is a subtle bug where-in due to the recent change to share the credential across all repositories shared on the same domain (so for Azure DevOps any repository), if a repository is though to be "dead" according to GitHub desktop, the credentials will be happily removed.

Another way to test the above is to remove ALL repositories except a single one in GitHub desktop and see if the behavior reappears.

I can say that I've been running and committing for the last few hours on 3.3.17 without issue after clearing out the old repositories that I could no longer access.

sergiou87 commented 5 months ago

Hey everyone 👋

We're very sorry for all these issues. We're looking for a solution to this problem and will let you know as soon as we have something that you could try out.

Thank you for your patience 🙇‍♂

aolszowka commented 5 months ago

Just to recap here as this appears to have "fixed it" for me (2 days now of not having this reset my creds):

Delete all "Legacy" Credential Formats from the Windows Credentials in the Credential Manager, under Generic Credentials look for GitHub - dev.azure.com and trash all of these
In GitHub Desktop make sure that you've removed any repositories that are no longer accessible (IE deleted/removed/disabled)
Allow the application to create a new set of creds this will create them in the "New" format of GitHub- dev.azure.com/email@address.com

This doesn't resolve the issue with multiple orgs having different PAT's but if you've got a single org tied to the same PAT you'll at least get back in a workable state.

Gabriel-Lacatus commented 4 months ago

Just to recap here as this appears to have "fixed it" for me (2 days now of not having this reset my creds):

Delete all "Legacy" Credential Formats from the Windows Credentials in the Credential Manager, under Generic Credentials look for GitHub - dev.azure.com and trash all of these

In GitHub Desktop make sure that you've removed any repositories that are no longer accessible (IE deleted/removed/disabled)

Allow the application to create a new set of creds this will create them in the "New" format of GitHub- dev.azure.com/email@address.com

This doesn't resolve the issue with multiple orgs having different PAT's but if you've got a single org tied to the same PAT you'll at least get back in a workable state.

I've tried this and it's like a game of whack-a-mole.

I think the authentication change was (very) shortsighted. Since all the repositories in DevOps are on the same domain, you can't just save one set of credentials. Moreover the simple combination of the domain "dev.azure.com" and a simple username is also not globally unique. The same username is generated in different DevOps Organizations but now this becomes ambiguous.

This is what happens:

I go to Credential Manager and delete all credentials of the form "GitHub - dev,azure.com/my.username"
I open GitHub Desktop and I go to the first repo in the list, let's call this OrgA/Repo1 (i.e. Repository 1 in Organization A)
I click Fetch, the login dialog appears
I go to Repo 1 in Org A, generate new credentials
the username is "my.username" because the full MS account I authenticate with is my.username@OrgA.com
input credentials in the GitHub Desktop dialog, Fetch now works
I select Repo 2 in Org A, Fetch works
I select Repo 3 in Org A, Fetch works
I select Repo 4 in Org A, Fetch works
now, I select Repo 5 in Org B
try to Fetch, the authentication Error popup shows up (not the login one!)
dismiss the popup, click Fetch again, now the login dialog shows up
I go to Repo 5 in Org B, generate new credentials
the username in this case is still "my.username" but now this is because the MS account I authenticate here is my.username@OrgB.com - is this where everything falls apart I wonder??? same username but each are from different Orgs/Tenants
I check Credential Manager, and sure enough there is only one entry "GitHub - dev.azure.com/my.username" --> but now which one is it? The one for Org A or the one for Org B?
the Fetch on Repo5 in Org B now works
I select Repo 6 in Org B, Fetch works
I select Repo 7 in Org B, Fetch works
and now the frustrating part: I go back to Repo 1 in Org A, and the authentication error popup appears and together with it a few of my neurons part ways with me...

So it would seem that as long as you work with only one Azure DevOps Org, it works fine but as soon as you are more eccentric and use a second one, more than that with the same username, this things becomes very confusing for the app and falls apart.

MatthewSteeples commented 4 months ago

@Gabriel-Lacatus I don't know if this is a helpful mitigation at all, but Azure DevOps ignores the username when authenticating, so you can put whatever you want in there to make it unique for your purposes

Airell commented 4 months ago

@trains78 Can you please update to the latest (being 3.3.17) and let us know if you are still having issues?

Still an issue in 3.3.18 (and using the DevOps repository in OCI, GutHub and company hosted Gitea).

trains78 commented 4 months ago

@trains78 Can you please update to the latest (being 3.3.17) and let us know if you are still having issues?

Still an issue in 3.3.18 (and using the DevOps repository in OCI).

My developers and I resolved this issue with updating to the latest version using the altKey and "Ensure Latest Version" For me this updated to 3.3.17. But currently using 3.3.18 without the error.

WizardJosh commented 4 months ago

Just chiming in as well as this happened to me this morning on 3.3.18 Update. I found GithubDesktop.exe in /Users/MyUsername/AppData/Local/GutHubDesktop -- There are folders starting with app-version # I simply renamed the app-3.3.18 folder to something different and the exe launched the 3.3.17 version. Just FYI if someone needs a quick workaround while this is looked into.

Gabriel-Lacatus commented 4 months ago

@Gabriel-Lacatus I don't know if this is a helpful mitigation at all, but Azure DevOps ignores the username when authenticating, so you can put whatever you want in there to make it unique for your purposes

Yes, any user name is accepted but the app is very keen on deleting stored credentials for the first Org after I switch to the second Org and get the authentication error. So again a game of whack-a-mole:

select Repo 1 on Org A
login dialog appears
go to Dev Ops in Org A, generate credentials
use unique user name but the generated password above
Fetch/Pull on Repo 1 works
I can see the credentials stored in Credential Manager
select Repo 2 on Org B
click Fetch, the Authentication Failed error popup appears (not the login dialog!)
check in Credential Manager, the credentials for Org A is now deleted
dismiss error popup
click Fetch Again, now the login dialog appears
go to Dev Ops in Org B, generate credentials
use unique user name but the generated password above
check in Credential Manager and the credential for Org B is stored
Fetch/Pull on Repo 2 in Org B now works
select Repo 1 in Org A
click Fetch... you guessed it... authentication error popup 😡

hszequel commented 4 months ago

See this comment: https://github.com/desktop/desktop/issues/18612#issuecomment-2116242545

weixihd commented 4 months ago

I started with version 3.3.17, and suddenly one day I needed to authenticate every operation. I later updated the version to 3.3.18, but the problem still exists. My colleague does not have this problem. What can I do to solve this problem?

tilemanrenovations commented 4 months ago

Hello there me. I’m glad to hear you’re doing well now. lol. Well I always say you always laughing or crying and I’d rather laugh. That’s just me though lol.

tilemanrenovations commented 4 months ago

Sorry for the blog. It’s against the rules you know.

sergiou87 commented 4 months ago

Hello 👋

Please, try the latest beta (3.3.19-beta2) from https://desktop.github.com/beta which includes support for multiple git credentials on the same host based on different repository paths and let us know if it works.

After updating, you might need to re-enter your credentials for your Azure DevOps repositories.

For hosts other than dev.azure.com, you might need to set useHttpPath to true for whatever domain your repos are hosted on. For example, for gitlab:

git config --global credential.https://gitlab.com.useHttpPath true

Thank you for your patience 🙏

Airell commented 4 months ago

With 3.3.19-beta2 still unable to connect to OCI DevOps Repository on 'https://devops.scmservice.eu-amsterdam-1.oci.oraclecloud.com' . Works on 3.3.14 with <tenant>/<user-email> + Auth token .

Cleaned my Windows Credentials and have tried git config --global credential.https://devops.scmservice.eu-amsterdam-1.oci.oraclecloud.com.useHttpPath true .

[credential "https://devops.scmservice.eu-amsterdam-1.oci.oraclecloud.com"]
    provider = generic
    useHttpPath = true

sergiou87 commented 4 months ago

@Airell could you share your log files, please? 🙏

Gabriel-Lacatus commented 4 months ago

so far so good, will keep an eye on this

Airell commented 4 months ago

@Airell could you share your log files, please? 🙏

I reverted back to 3.3.14, updated to the 3.3.19-beta2 again to collect logs, but now it seems to work... 🤔

Woudjee commented 4 months ago

@sergiou87 I just checked out your the comment you referenced in the other thread. So if I understand correctly:

It's a known issue
In the beta version you mentioned, I will most likely not experience the issue?

If that's the case, I will try it out next week when I'm on my work laptop again :) Thank you!

desktop / desktop