A password is suddenly asked on my token access to github, and even the error message quote it as outdated.

[ThibauldMichel]

Select Topic Area

Question

Body

I have set up my local git to access to Github via access token using this command:

git push https://<GITHUB_ACCESS_TOKEN>@github.com/<GITHUB_USERNAME>/<REPOSITORY_NAME>.git

Until recently it worked well.
But for an unknown reason, a password was asked when I used the same command line yesterday.
Ironically, the error message itself quote this authentication method is outdated.

On branch master
nothing to commit, working tree clean
Password for 'https://<GITHUB_ACCESS_TOKEN>@github.com':
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/<GITHUB_USERNAME>/<REPOSITORY_NAME>.git/

So my questions are:

• Has anything changed recently in the authentication system that has made my git push script invalid?
• Why is there still the option to enter a password in git push/clone/etc... even though it is outdated and not usable anymore?

[ThibauldMichel]

Thank you very much for your patience and pedagogy. It is now perfectly clear why the changes have been made and what are the guidelines.

Kind regards,

Thibauld

[jphme]

@jzelAdmin2006

I am sorry but I don't understand this at all. I am locked out of imporntant Repos suddenly late at night with the same message:

remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for ...../'

I have absolutely no idea, why that message is suddenly displayed (the token was previously stored in the credential manager).

The linked URL in that error message is completely unhelpful. The link to the documentation you attached is also completely unhelpful. I have my ssh key even setup in GitHub. I know ssh. I have my PAT stored in an environment variable. Yet my workflow/muscle memory is still with https clone/remotes.

If you break workflows, please give us a simple step to fix this (e.g.: "enter these 3 commands to switch to ssh remote or enter these 3 commands to setup your git credential store newly"). I have to search for random Stackoverflow Threads on Google to fix this (still unsuccessfully ) because i have no idea from the error message why I suddenly can't access my repos anymore and what the solution is. Not cool!

[jphme]

Ok I was able to fix it. The reason? My Github PAT was expired....

I don't know if this is intended or for security reasons, but how in god´s name can an error message be so misleading?

[jphme]

@jzelAdmin2006 sorry for my tone, it was late at night and i was frustrated because I couldn't start a training run due to this ;-) .

As I wrote, I have my SSH keys generated (and even added to Github), I just never switched over to SSH.
I guess the correct way to update a remote (that would be what I searched for) would be something like git remote origin set-url git@github.com..... or would anything else be needed to switch over from a https-based remote to a ssh-based remote?

Many Thanks!

[philokalos-athos]

it works! thank you!

[ghostinhershell]

Hey there! 👋

Thanks for posting in the GitHub Community, @ThibauldMichel! We're happy you're here. You are more likely to get a useful response if you are posting your question in the applicable category. The Accessibility category is a place for our community to discuss and provide feedback on the digital accessibility of GitHub products. Digital accessibility means that GitHub tools, and technologies, are designed and developed so that people with disabilities can use them.

Also, if you did receive an answer to your question here, I would encourage you to mark the response as the answer so that it can help others who have similar questions find the answer in the future.

I've gone ahead and moved this to the correct category for you. Good luck!

[IkaLukava]

Useless Responses!!!

[burners-git-cicd]

Yes, doesn't solve anything. I need to automatically clone a different repo during build and I get all kind of "fatal: could not read Password for 'https://******@github.com': No such device or address" nonsense even when using a PAT.

This is really blocking my effort to get things going. Why not keep it simple but instead add more and more layers of security on top of it?

We need to be able to do our work and not spend days figuring out the latest "security improvement". Seriously. This needs to stop.

[rahulkolawale1999]

remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/rahulkolawale1999/DevOps.git/'

can someone give me the correct steps to solve this issue?

[ghost]

Yeah, I'm also suddenly started to get this error even tho already using PAT.

[ardole]

Same thing for me. I checked my PAT (not expired, full rights...etc.) and tried so many configurations.

Did you find something to fix ?

[IvanBisultanov]

POSSIBLE SOLUTION

When you asked for:

Password for 'https://<YOURGITHUB>@github.com':

This is not a password — it's a personal access token.

At least in my case 🙈

[wabmaster7]

I also have been confronted by this 'password' request this week ... even though the PAT was created in April 2024 with no exp date ... hmmm.

I created another github PAT with exp date six months out.

To fix, locally, for me:
git config --global credential.helper 'store --file ~/.git-credentials'
git remote set-url origin https://YOUR-USERNAME:YOUR-TOKEN@github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
git pull origin main

[KostyaCube]

It works! Thank you. This error really pissed me off.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[polarathene]

TL;DR: You can presently use the following to authenticate with a token:

# `gha` user can be anything:
git push https://gha:${GITHUB_TOKEN}@github.com/octocat/hello

---

Persistence

This is more relevant to CI usage where you may not want to persist the credentials to disk to perform various git operations.

If you git clone with a URL like that, you'll find the credentials are persisted at .git/config:

git config --local remote.origin.url

If you've already got a repo, you can update the remote url like already suggested with git remote set-url origin, or you can set base64 encoded credentials like actions/checkout does:

GH_CREDENTIALS=$(echo -n "gha:${TOKEN}" | base64 -w0)
git config --local http.https://github.com/.extraheader "AUTHORIZATION: basic ${GH_CREDENTIALS}"

# Credentials are scoped to Github rather than per remote:
git config get --local --url https://github.com http.extraheader

---

Original answer

I landed here when trying to perform git ls-remote to a private repo during a GHA workflow. It was reliant upon actions/checkout persisting credentials, and I was curious if it could just leverage the token it already had without a checkout.

Various sources implied that this was not supported, it's unclear why official docs don't mention it.

I have set up my local git to access to Github via access token using this command:

git push https://<GITHUB_ACCESS_TOKEN>@github.com/<GITHUB_USERNAME>/<REPOSITORY_NAME>.git

Until recently it worked well. But for an unknown reason, a password was asked when I used the same command line yesterday. Ironically, the error message itself quote this authentication method is outdated.

I have found the following to work in a private repo when used in a GHA workflow run:

git ls-remote --exit-code --refs --tags --sort='-v:refname' \
https://gha:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.event.repository.full_name }}

Compared to the quoted example, the solution uses basic-auth credentials URL (https://user:password@url) (NOTE: The link expresses this support is deprecated in web browsers). The password needs to be a valid token, but the username can be anything it seems.

It's possible that this isn't intended to be supported still, but it does work outside of actions too if you've created a personal token (again the username portion is not relevant, but a username of at least one character is required).

---

While the solution does differ from the alternative forms that were originally blogged (neither considered valid today), the blog does show roughly the same basic-auth syntax support - except the token is treated as the username which the blog explains:

We decided to use the token as the HTTP username to avoid colliding with credential helpers available for OS X, Windows, and Linux.

That blog also does warn you about a risk of the token being persisted to disk:

Note: Tokens should be treated as passwords.
Putting the token in the clone URL will result in Git writing it to the .git/config file in plain text.

To avoid writing tokens to disk, don’t clone.
Instead, just use the full git URL in your push/pull operations

I'm not familiar with if that's only the case with git clone. If you are concerned, you can verify if it's safe with:

FROM fedora:42
RUN dnf install -qy git

COPY --chmod=500 <<"HEREDOC" /usr/local/bin/run-example
#!/usr/bin/env bash

TOKEN=your-token-here
REPO='owner/repo'
REPO_URL="https://gha:${TOKEN}@github.com/${REPO}"

# No credentials stored:
git ls-remote --exit-code --refs --tags --sort='-v:refname' "${REPO_URL}" > /tmp/results.txt

# Credentials stored at `./example/.git/config`:
git clone "${REPO_URL}" example
HEREDOC

WORKDIR /tmp
RUN run-example

I used a docker image from the above Dockerfile to inspect it's layers with dive as a way to ensure that the RUN layer didn't write to disk anywhere else unexpectedly. Alternatively test via terminal and a temporary token scoped to a test repo.

After the clone, change to the clone dir (/tmp/example) and you'll see credentials persisted to the local .git/config:

# Show's the specific config entry that persisted the basic-auth URL (plain-text credentials):
git config --local remote.origin.url

---

NOTE: GitHub Actions actions/checkout has the same risk by default with it's own cloning (persists slightly differently), roughly it looks like this:

# Initialize a new repo
git init

# Add the remote origin without credentials associated to it:
git remote add origin ${{ github.event.repository.html_url }}

# Add the authorization credentials for that remote via basic-auth header, requires base64 encoding:
GH_CREDENTIALS=$(echo -n "gha:${TOKEN}" | base64 -w0)
git config --local http.https://github.com/.extraheader "AUTHORIZATION: basic ${GH_CREDENTIALS}"

# Retrieve the specific line with base64 encoded credentials set (or see full config via `cat .git/config`):
git config get --local --url https://github.com http.extraheader