You’re in the middle of something. Maybe you’re pushing a hotfix, maybe you’re cloning a repo on a new machine, maybe you’re just trying to pull the latest changes. And then this shows up:
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/USERNAME/REPO.git'Or maybe you see this version:
fatal: Authentication failed for 'https://gitlab.com/USERNAME/REPO.git'Either way, Git just refused to let you in. No code got pushed. No repo got cloned. Just a blunt rejection.
Here’s what most people do at this point: they try their password again, get rejected again, start Googling, find three different answers that all contradict each other, try one thing that doesn’t work, and then spend 45 minutes more frustrated than when they started.
This guide skips all of that. It covers every proven cause of the Git authentication failed error, gives you a clear way to diagnose which one applies to you, and walks you through the exact fix — step by step — for each one. By the end, you’ll have it resolved and know exactly how to keep it from coming back.
Let’s dig in.
Git Authentication Failed Error – 7 Proven Fixes (Step-by-Step Guide)
What Is the Git Authentication Failed Error?
The full error message looks like one of these, depending on your platform and setup:
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/USERNAME/REPO.git'
remote: HTTP Basic: Access denied.
fatal: Authentication failed for 'https://gitlab.com/USERNAME/REPO.git'
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/USERNAME/REPO.git'
fatal: could not read Username for 'https://github.com': terminal prompts disabled
error: 1024-bit RSA keys are not allowed
Authentication failedAll of these boil down to the same core problem: Git tried to authenticate your identity with the remote server, and it failed. The server rejected the credentials you provided — or no credentials were provided at all.
This happens on GitHub, GitLab, Bitbucket, Azure DevOps, and any other Git hosting platform. The fixes in this guide cover all of them.
One important thing to understand upfront: this error is almost always about credentials, tokens, or configuration — not about your code, your repository, or your network. The issue lives in how Git is proving your identity, not in the repository itself.
Why Does Git Authentication Fail?
Authentication with a remote Git repository can happen in two ways: over HTTPS (using a username and password or a personal access token) or over SSH (using a key pair). This error almost exclusively affects HTTPS-based authentication. If you’re using SSH and hit an authentication error, the publickey guide covers that scenario.
For HTTPS authentication, here are the most common reasons the error appears:
GitHub and GitLab removed password-based authentication. Starting August 2021, GitHub stopped accepting plain account passwords for Git operations. GitLab followed with similar changes. If you’re still typing your account password when Git prompts you, that’s the reason it’s failing.
Your personal access token expired or was revoked. Tokens have expiry dates. If yours expired, Git will reject it exactly like a wrong password — with no explanation about the actual cause.
Your credentials are cached incorrectly. Your operating system’s credential manager (Keychain on macOS, Credential Manager on Windows, or libsecret on Linux) may be storing outdated or wrong credentials and automatically sending them without prompting you.
You don’t have the right permissions on the repository. You’re authenticated successfully, but your account doesn’t have access to that specific repo, or the token you’re using doesn’t have the required scopes.
Two-factor authentication is enabled. 2FA on your account changes how HTTPS authentication works and requires a token instead of a password.
You’re in an environment where terminal prompts are disabled. CI/CD pipelines, scripts, and some IDEs can’t handle interactive username/password prompts, leading to “terminal prompts disabled” errors.
The remote URL is wrong or malformed. Typing errors in the repository URL or username can make Git try to authenticate with a server or endpoint that doesn’t exist.
Now let’s fix each of these, one by one.
Fix 1 — Generate and Use a Personal Access Token (The Most Common Fix)
This resolves the error for the majority of people hitting it today. Since GitHub deprecated password authentication in August 2021 and GitLab made similar changes, a personal access token (PAT) is the required replacement for HTTPS authentication.
A personal access token is a string that looks like this:
ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You use it exactly like a password — paste it in when Git asks for a password. The difference is that it’s generated by GitHub (not your actual account password) and has configurable expiry dates and permission scopes.
How to Generate a Token on GitHub
Log in to GitHub and click your profile photo in the top right. Go to Settings, then scroll down the left sidebar and click Developer settings. Click Personal access tokens, then Tokens (classic), then Generate new token.
Give the token a descriptive name so you remember what it’s for — something like “Work laptop Git access” rather than just “token.”
Set an expiration date. GitHub strongly recommends not setting tokens to never expire, but if you want low-maintenance access for a personal machine, 90 days or 1 year is a reasonable choice.
Under scopes, select repo. This gives the token read and write access to your repositories. If you need to access GitHub Actions, packages, or other features, select those scopes too.
Click Generate token. Copy the token immediately and store it somewhere safe — GitHub will only show it once.
How to Generate a Token on GitLab
Go to your GitLab profile → Preferences → Access tokens. Give it a name, set an expiry date, and select the read_repository and write_repository scopes (or api for full access). Click Create personal access token and copy the result.
How to Use the Token
When you next run a Git command that requires authentication, Git will prompt you:
Username for 'https://github.com': your-github-username
Password for 'https://your-github-username@github.com':Enter your GitHub username at the first prompt. At the password prompt, paste the personal access token — not your account password. Press Enter.
If you want Git to remember the token so you’re not prompted every time, jump ahead to Fix 3 which covers credential caching.
Fix 2 — Clear Stale Cached Credentials
This is the fix for people who generated a token but Git keeps using the old wrong credentials anyway. Your OS credential manager stored the old password or expired token, and it’s sending that automatically without asking you. You need to clear it out so Git falls back to prompting you for fresh credentials.
On macOS — Keychain Access
macOS stores Git credentials in the Keychain. The quickest way to clear them:
git credential-osxkeychain erase
host=github.com
protocol=httpsPress Enter after the last line, then press Enter one more time on a blank line to execute the command. After this, Git will prompt for credentials on your next push or pull.
Alternatively, open Keychain Access from Applications → Utilities, search for “github.com” or “gitlab.com”, find the entry, and delete it manually.
On Windows — Credential Manager
Open the Start menu and search for Credential Manager. Open it and click Windows Credentials. Scroll through the list and look for entries containing github.com, gitlab.com, or git. Click the entry to expand it, then click Remove.
After deleting the entry, run your Git command again and enter your username and personal access token when prompted.
You can also clear credentials from the command line in Git Bash:
git credential reject
host=github.com
protocol=httpsPress Enter twice after the last line.
On Linux
If you’re using the Git credential store (a plain text file):
git config --global --unset credential.helperThen remove the stored credentials file:
rm ~/.git-credentialsIf you’re using libsecret or GNOME Keyring:
git credential-gnome-keyring erase
host=github.com
protocol=httpsAfter clearing credentials, run your Git command and enter your username and token when prompted.
Fix 3 — Set Up Credential Caching So You Stop Being Prompted
Once you have a working personal access token, you probably don’t want to paste it every single time you push. Git has a built-in credential helper that stores your credentials securely in the OS.
On macOS
macOS has a native credential helper that integrates with Keychain. Make sure it’s configured:
git config --global credential.helper osxkeychainAfter setting this, the next time Git asks for credentials and you enter your token, macOS will store it in Keychain automatically. Every subsequent Git operation will use it without prompting.
On Windows
Git for Windows ships with a credential manager. Install Git Credential Manager if you don’t have it already (it comes bundled with Git for Windows by default since version 2.29). Set it up:
git config --global credential.helper managerThis stores credentials in Windows Credential Manager with encryption. When you next authenticate, a GUI prompt will appear for your username and token, and subsequent operations will use the stored credentials automatically.
On Linux
On Linux, the simplest option is the cache helper, which holds credentials in memory for a configurable duration:
git config --global credential.helper 'cache --timeout=3600'This keeps credentials in memory for one hour (3600 seconds). Adjust the timeout as needed. For permanent storage, install Git Credential Manager for Linux or use the store helper (note: this stores credentials in plain text in ~/.git-credentials, so only use it on machines where that’s acceptable):
git config --global credential.helper storeFix 4 — Check and Fix Repository Permissions
Sometimes Git authenticates successfully but still returns an authentication error because your account doesn’t have access to the specific repository. This is more common in organization or team contexts.
Run this to verify your authentication is working at all:
On GitHub:
ssh -T git@github.com
On GitLab:
ssh -T git@gitlab.com
If you see “Hi username! You’ve successfully authenticated,” your credentials work. The issue is permissions on the repo itself.
Things to check:
You might be trying to push to a repository you only have read access to. Ask the repository owner to grant you write access.
If it’s an organization repository, your organization membership might need to be confirmed. Go to the organization page on GitHub and accept the membership invitation if one is pending.
If you’re using a personal access token, check whether it has the right scopes. A token with only read:user scope can’t push code. You need the repo scope for full repository access. Go to GitHub → Settings → Developer settings → Personal access tokens and verify or regenerate the token with the correct scopes.
For private repositories, make sure you’re using the token belonging to an account that has been granted access. If someone else owns the repo and you’re a collaborator, your token still needs repo scope, and the owner needs to have added you as a collaborator.
Fix 5 — Fix Authentication in CI/CD Pipelines and Scripts
In automated environments — GitHub Actions, GitLab CI, Jenkins, shell scripts — Git can’t show you an interactive password prompt. When it can’t prompt, you get this error:
fatal: could not read Username for 'https://github.com': terminal prompts disabledThe fix is to embed the credentials directly in the remote URL or use environment variables, so Git never needs to prompt.
Using a Token in the Remote URL
Set the remote URL to include the token:
git remote set-url origin https://TOKEN@github.com/USERNAME/REPO.gitReplace TOKEN with your personal access token and USERNAME/REPO.git with your actual repository path.
For one-off commands without changing the remote:
git clone https://TOKEN@github.com/USERNAME/REPO.gitUsing Environment Variables (Recommended for CI/CD)
In GitHub Actions, use the built-in GITHUB_TOKEN secret:
name: Checkout
uses: actions/checkout@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}For pushing from a GitHub Actions workflow:
git remote set-url origin https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}In GitLab CI, use CI_JOB_TOKEN:
git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/USERNAME/REPO.gitFor Jenkins or other CI systems, store your personal access token as a secret credential in the CI platform and inject it as an environment variable, then use it in the remote URL as shown above.
Never hardcode tokens in your source code or commit them to a repository. Always use the CI platform’s secrets management.
Fix 6 — Handle Two-Factor Authentication (2FA)
If your GitHub or GitLab account has two-factor authentication enabled, it affects how HTTPS authentication works — but not in the way you might expect.
2FA on your account does not mean you enter a 2FA code when running git push. It means your regular account password is completely disabled for Git operations over HTTPS. You must use a personal access token instead.
So if 2FA is enabled and you’re still trying to use your account password, that’s why it’s failing. The fix is exactly what Fix 1 describes — generate a personal access token and use that as the password.
The token-based authentication flow does not involve a 2FA prompt during git push. You simply use the token, and it works. Two-factor authentication at the Git command line level isn’t a thing — the token itself is the second factor.
If you’re sure you’re using a token and still seeing issues with 2FA enabled:
Check that the token has the right scopes (repo at minimum for private repositories).
Make sure you’re entering your GitHub username at the username prompt — not your email address.
Verify that the token hasn’t expired in your GitHub settings.
Fix 7 — Fix the Remote URL
A wrong or malformed remote URL is the most overlooked cause of this error. If the URL points to the wrong username, wrong repository name, or the wrong protocol, Git will try to authenticate with something that doesn’t exist.
First, check your current remote URL:
git remote -vYou should see something like:
origin https://github.com/USERNAME/REPO.git (fetch)
origin https://github.com/USERNAME/REPO.git (push)Things that can go wrong:
Wrong username in the URL — If the URL shows the wrong GitHub username, Git is trying to authenticate against a different account’s repository. Fix it:
git remote set-url origin https://github.com/CORRECT-USERNAME/REPO.gitTypo in the repository name — Double-check the exact name of the repository on GitHub. Repository names are case-sensitive.
Using git:// protocol — The git:// protocol is unauthenticated and read-only. If your remote URL starts with git://, change it to https://:git remote set-url origin https://github.com/USERNAME/REPO.gitSwitching from HTTPS to SSH — If you’ve set up SSH keys and want to switch away from HTTPS authentication entirely (a great long-term solution), update the remote URL to use SSH:
git remote set-url origin git@github.com:USERNAME/REPO.gitAfter switching to SSH, the “authentication failed” error becomes irrelevant for that repository because SSH key authentication takes over. See the publickey guide for SSH setup details if you haven’t done that yet.
After updating the remote URL, run git remote -v again to confirm the change, then retry your Git command.
Real Terminal Example — Diagnosing and Fixing From Scratch
Here’s a complete session showing what the diagnosis and fix process looks like in practice on a macOS machine where the cached credentials had expired:
$ git push origin main
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/devuser/my-project.git'$ git remote -v
origin https://github.com/devuser/my-project.git (fetch)
origin https://github.com/devuser/my-project.git (push)
[Remote URL is correct — credentials must be the issue]$ git credential-osxkeychain erase
host=github.com
protocol=https[pressed Enter twice to execute]
[Generated a new personal access token on GitHub with repo scope]
$ git push origin main
Username for 'https://github.com': devuser
Password for 'https://devuser@github.com': [pasted token here]
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 284 bytes | 284.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
To https://github.com/devuser/my-project.git
a1b2c3d..e4f5g6h main -> main[Credentials automatically saved to macOS Keychain for future use]
$ git push origin main
[No prompt — uses cached token]
Everything up-to-date.Total time from error to working push: under four minutes.
Prevention Tips — How to Avoid This Error Going Forward
Fixing the error once is table stakes. Here’s how to stay ahead of it.
Tip 1 — Set Token Expiry Reminders
Personal access tokens with expiry dates are more secure, but they’ll break your Git access silently when they expire. Set a calendar reminder one week before your token expires to generate a new one and update your credential manager. This takes about two minutes and saves you from a surprise mid-project.
Tip 2 — Switch to SSH for Long-Term Simplicity
HTTPS with tokens requires periodic renewal and credential management. SSH key authentication, once set up, works indefinitely on the same machine without token expiry or credential caching to worry about. If you find yourself hitting authentication issues repeatedly, switching your remotes to SSH is the permanent solution.
To switch a repository from HTTPS to SSH:
git remote set-url origin git@github.com:USERNAME/REPO.git
Do this once per repository and you’ll never see “authentication failed” on that repo again.
Tip 3 — Use Git Credential Manager
Git Credential Manager (GCM) is an open-source tool from Microsoft that handles authentication for GitHub, GitLab, Bitbucket, and Azure DevOps in a unified, secure way. It supports OAuth flows, personal access tokens, and SSH. It’s bundled with Git for Windows and available for macOS and Linux.
Once installed, it handles token storage, renewal prompts, and multi-account scenarios automatically. It’s the closest thing to “set it and forget it” for Git HTTPS authentication.
Install it from: https://github.com/git-ecosystem/git-credential-manager
Tip 4 — Use Fine-Grained Tokens for Sensitive Repositories
GitHub now offers fine-grained personal access tokens that let you restrict a token to specific repositories and specific actions (read-only vs read-write, issues, pull requests, etc.). For any repository containing sensitive code or production infrastructure, use a fine-grained token with the minimum permissions required. This limits the blast radius if a token is ever accidentally exposed.
Tip 5 — Never Store Tokens in Code or .env Files You Commit
A personal access token found in a public repository is a full compromise of your GitHub account for everything that token has access to. Git pre-commit hooks, tools like git-secrets, and GitHub’s own push protection can scan for token patterns before they’re committed. Enable push protection on your GitHub account under Settings → Code security and analysis.
Tip 6 — Document Which Token Is for What
If you work across multiple machines and multiple platforms, you can end up with a dozen tokens in your GitHub settings with no idea which one does what. Name tokens clearly (“MacBook Pro — personal repos”), set sensible expiry dates, and delete tokens for machines you no longer use. A clean token list is easier to audit and more secure.
FAQ
Q: Why did Git authentication suddenly stop working when it was fine before?
The most common reason is that your personal access token expired. GitHub and GitLab tokens have expiry dates, and when they expire, Git rejects them silently with the same “authentication failed” error you’d see for a wrong password. Go to GitHub → Settings → Developer settings → Personal access tokens and check whether your token is expired. Generate a new one if it is, then clear your cached credentials (Fix 2) and re-enter the new token.
Q: Do I need a separate token for each repository?
No. One personal access token with repo scope works for all repositories your account can access — both public and private. You only need multiple tokens if you want to restrict access to specific repositories (using fine-grained tokens) or if you’re operating across multiple GitHub accounts.
Q: Why does Git ask for a username AND password when I thought tokens replace passwords?
The way HTTPS Git authentication works, Git still presents the same username/password prompt whether you’re entering a real password or a token. The difference is what you type at the password prompt. Enter your GitHub username at the username prompt, and paste the personal access token at the password prompt. The token is the password as far as the prompt is concerned.
Q: I’m getting “remote: Repository not found” — is that an authentication error?
Yes, often. “Repository not found” can mean the repository genuinely doesn’t exist, but it can also mean the repository is private and you’re either not authenticated or authenticated as the wrong user. GitHub shows this generic message intentionally to avoid confirming the existence of private repositories to unauthenticated users. Check your credentials and remote URL first before assuming the repo is missing.
Q: Can I use my GitHub email address as the username?
No. When Git prompts for a username, enter your GitHub username (the handle that appears in your profile URL, like github.com/yourusername), not your email address. Using your email instead of your username is a common mistake that causes authentication to fail even with a correct token.
Q: How do I fix this in VS Code or another IDE?
Most IDEs that integrate with Git use the same OS credential manager that the command line does. If you fix the credentials on the command line using Fix 2 and Fix 3 above, the IDE will pick up the new credentials automatically. If VS Code specifically is prompting you, look for a “Sign in to GitHub” option in the Source Control panel, which uses OAuth and is the most seamless way to authenticate from within VS Code.
Q: I’m using GitHub Actions and getting “Authentication failed” — how do I fix it?
The built-in GITHUB_TOKEN should handle authentication in most GitHub Actions workflows without any manual setup. If you’re seeing authentication errors in Actions, the most likely causes are: the workflow is trying to push to a repository that GITHUB_TOKEN doesn’t have write access to (you may need to set permissions: write-all in the workflow file or use a PAT stored as a secret), or you’re cloning a private external repository and need to provide a PAT. See Fix 5 for the full CI/CD authentication setup.
Q: What’s the difference between a classic token and a fine-grained token?
Classic personal access tokens apply broadly to all repositories your account can access, with coarse permission scopes like repo or read:user. Fine-grained tokens let you restrict access to specific repositories and specific actions (e.g., read-only access to one private repo). Fine-grained tokens are more secure for anything beyond personal use. GitHub is gradually pushing toward fine-grained tokens as the default, though classic tokens still work.
Q: Is it safe to put a token in the remote URL?
Using a token in the remote URL (https://TOKEN@github.com/…) works, but it means the token appears in your shell history and in the output of git remote -v, which is a security risk on shared machines. For local development, use the credential manager approach (Fix 3) instead. For CI/CD, use environment variables or the platform’s secrets management rather than hardcoding the token in the URL in any file that gets committed.
Q: Git works on the command line but fails in my deployment script. Why?
Scripts and deployment environments often run as a different user (like www-data, deploy, or a service account) that doesn’t have the same credentials configured as your personal user account. The credential manager stores credentials per user. Either configure credentials for the service account, use SSH key authentication with a deploy key, or embed the token in the remote URL using an environment variable. Deploy keys (SSH keys with access to a single repository) are the cleanest solution for deployment scenarios.
Related Errors
These errors are closely related to authentication failure and often appear in the same troubleshooting session.
remote: Support for password authentication was removed
This is GitHub’s specific message for anyone still trying to use their account password after August 2021. It’s not just “authentication failed” — it’s telling you exactly why. The fix is Fix 1: generate a personal access token and use that instead of your password.
error: The requested URL returned error: 403
A 403 means the server understood your request but refused it. Usually this means you authenticated successfully but don’t have permission to perform the action you’re trying to (like pushing to a repository you only have read access to). Check your repository permissions and token scopes.
error: The requested URL returned error: 401
A 401 means the server couldn’t authenticate you at all. This is the direct HTTP counterpart to “authentication failed.” Usually means wrong credentials, expired token, or no credentials provided. Work through Fix 1 and Fix 2.
git@github.com: Permission denied (publickey)
This is the SSH equivalent of authentication failed — but for SSH-based connections rather than HTTPS. If your remote URL starts with git@ instead of https://, this is the error you’ll see when SSH authentication fails. This is covered in full in the Git Permission Denied (publickey) guide.
fatal: repository ‘https://github.com/…’ not found
Can appear when you’re unauthenticated and trying to access a private repository, or when the URL is wrong. GitHub intentionally returns “not found” rather than “forbidden” for private repositories to avoid revealing their existence. Check the URL and your credentials.
fatal: unable to access ‘https://github.com/…’: The SSL certificate problem
Not an authentication error but often confused for one. This means there’s a TLS/SSL certificate verification failure — common in corporate networks with SSL inspection proxies. Talk to your network administrator or, as a temporary workaround: git config –global http.sslVerify false (only on networks you trust fully).
Conclusion
Git authentication failures feel urgent and confusing in the moment, but they’re almost always caused by one of a handful of well-understood issues — an expired token, stale cached credentials, missing token scopes, a wrong remote URL, or a CI/CD environment that can’t handle interactive prompts.
The fix that solves the error for most people today is Fix 1: replace your account password with a personal access token. GitHub made this mandatory in 2021 and GitLab followed suit. If you’re still using your account password for HTTPS Git operations, that’s the entire reason for the error, and generating a token takes less than two minutes.
After the immediate fix, the two things worth doing for long-term stability are setting up your OS credential manager properly (Fix 3) so you’re not prompted constantly, and considering a switch to SSH authentication (Fix 7) so token expiry never becomes an issue again. SSH key authentication, once configured, works indefinitely on the same machine without maintenance.
If you’ve been through every fix in this guide and the error persists, look at the exact wording of the error message carefully. GitHub and GitLab often include specific hints in the error text — “Support for password authentication was removed” tells you exactly what to do. “Repository not found” points to a URL or permission issue. The error message is rarely as cryptic as it first appears.
The Git authentication system is well-designed once you understand it. A few minutes of setup and you’ll have smooth, uninterrupted access to every repository you work with.
Related Resources
GitHub Docs — Creating a personal access token (classic)
GitHub Docs — Fine-grained personal access tokens
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.
If this saved you time, consider bookmarking it for next time — or sharing it with a teammate who’s hitting the same wall right now.