“remote: Invalid username or password” or “fatal: Authentication failed” occurs before Git can negotiate a successful authenticated operation. It is distinct from non-fast-forward push rejection, which means authorization succeeded but your branch history conflicts.
This guide is for Git authentication failed in its stated software or device context. Capture the exact message and the operation that fails; the same keyword may have different meanings in another application. A reliable diagnosis identifies an observable difference, not just a plausible cause.
Recognize the symptoms
- `git pull` or `git push` fails with authentication rejected from a GitHub HTTPS remote.
- A token recently expired, account changed or organization enabled SAML SSO.
- The same repository works in the browser but CLI requests fail under a different credential.
Record the software version, device or server role, first failure time and any update or configuration change immediately before the incident. Compare whether the symptom affects one file, one user, one device or the entire service. These observations guide the safest first test.
Before making changes
Keep a restorable copy of important files, settings and credentials wherever the procedure might modify them. Use the original account, workflow and network for comparison. Perform one controlled change at a time, record the outcome, and undo changes that do not affect the failure.
If the action can create payments, data writes, account changes or destructive storage activity, do not retry it automatically. Confirm whether the previous operation already succeeded. Managed devices, production databases and service infrastructure require the owner’s authorization.
Step-by-Step Troubleshooting
Choose Beginner for reversible checks; Advanced covers evidence-based inspection, bounded changes and verification.
Identify host, protocol and operation
Use `git remote -v` to inspect whether the URL is HTTPS or SSH and whether the host is github.com or enterprise GitHub. Do not paste token-bearing remote URLs into public logs.
Confirm correct GitHub identity and repository access
Sign in through your trusted browser to verify which account owns or can access the repository. A private repo that is invisible to that account cannot be repaired with a cache clear.
Refresh official credential-manager sign-in
Use Git Credential Manager or the helper approved by your environment to update the relevant host credential. Avoid embedding access tokens in remote URLs or shell history.
Retry a safe read operation first
Start with `git ls-remote` or a fetch, then try an authorized push if needed. Different outcomes separate credential failure from missing write permission or branch-protection rules.
Inspect configured credential helpers
List the credential helper and URL rewrite configuration without dumping stored secrets. A credential for the wrong username or host can be selected even when browser login is correct.
git remote -vgit config --show-origin --get-all credential.helpergit ls-remote origin HEADCheck token, scope and SSO boundaries
Review personal access token expiration, fine-grained resource access and any GitHub Enterprise organization SSO requirements. Rotate or authorize through official GitHub controls only.
Separate HTTPS auth from SSH diagnostics
If the project intentionally uses SSH, check trusted SSH-agent identities and repository authorization. Do not blindly switch protocols or paste private keys to a remote support service.
Repair the smallest authentication setting
Replace only the stale credential, correct a mismatched remote URL or request the necessary repository permission. Re-test read and write operations and record the working helper configuration.
Diagnosis: identify the layer that is actually failing
Start with the evidence collected by the Beginner or Advanced tab, then compare the patterns below. A match is a working hypothesis; it is not proof until the original operation succeeds after a targeted, reversible change.
| Observed pattern | Evidence to inspect | Most useful next step |
|---|---|---|
| Browser access works, Git fails | Remote URL and credential-helper account | Refresh authorized CLI credentials. |
| Only one organization fails | Org SSO and token/resource restrictions | Review organization-approved authorization. |
| Read works, push fails | Repository write permission and branch rules | Distinguish authentication from branch authorization. |
Common root causes to rule in or out
- A stale credential helper entry or wrong signed-in account.
- A token lacking repository access, permission scope or organization authorization.
- Remote host URL mismatch, wrong protocol or enterprise access policy.
A recent change establishes a useful timeline but not causation on its own. Look for a repeatable relationship: does the failure follow a particular account, release, host, storage volume or workload? Compare an unaffected example under nearly identical conditions before choosing any broad repair.
What each result means
When the same problem reproduces on multiple independent devices or clients, focus on shared account, service or infrastructure conditions. When it follows one client, check its runtime, policies and local state. When only one particular operation fails, inspect that workload before reinstalling unrelated components.
If a command or diagnostic produces a different result than the article describes, stop and interpret that actual output. Examples are not meant to be executed blindly: identifiers, installation paths, network ports and supported options can vary by version and permissions.
How to verify the repair
Return to the exact action that produced Git authentication failed. Repeat the safe test under the original account, environment and input conditions. An error disappearing after one reload is not enough if the underlying service still produces failures under normal use.
- Run an authenticated read against the correct origin.
- Test a normal authorized push to a safe branch if write access is required.
- Confirm credential storage follows organization security policy.
Confirm that the adjacent feature still works and that the protective controls, data and settings kept during diagnosis remain intact. Record the exact effective change and keep the rollback instructions; a completed checklist is a tracking aid, not a guarantee that all failure conditions are gone.
Solution Checklist
If the error remains: rollback and escalation
Revert a wrong remote URL or helper change and revoke any accidentally exposed tokens immediately. Organization policy blocks must be resolved with administrators.
Provide support with the redacted exact message, timestamps and timezone, version, environment, scope, relevant log excerpts and tests attempted. Do not include passwords, session cookies, license keys, complete private URLs or other secrets in public tickets.
How to prevent it from returning
- Use a credential manager or supported SSH key workflow.
- Set expiry reminders and least-privilege scopes for access tokens.
- Avoid sharing shell history or remote URLs that contain secrets.
Maintain a short incident note that distinguishes the confirmed cause from hypotheses that were tested and rejected. Update the note when a product release or platform policy changes the troubleshooting sequence.
Frequently asked questions
Why does GitHub login work in the browser but git push fails?
Browser cookies and command-line credentials are separate. Check the CLI helper, account, token and repository write rights.
Can git push –force fix Authentication failed?
No. Force push changes history semantics and cannot grant authentication or repository permission.
Further reading: official documentation
Editorial note: vendor interfaces, error-code behavior and supported versions may change. Confirm the relevant product documentation before deploying a change to a production or managed system. This draft does not claim that every remedy was tested on the reader’s environment.