Problem: Cloning a public repo fails: "Your account is suspended" (config/credential layer, not network) —— Trove problem library

What you will run into

Cloning a public repo (browser opens it fine, curl works too) fails with ERROR: Your account is suspended + fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. The wording is very misleading:

GitHub returns the same sentence for 403/404 on an invalid account, even for public repos, so it's easy to misdiagnose as network/repo problems.

The network is fine; the problem is in the git config/credential layer.

Why this happens

Most common: a global git config rewrites HTTPS to SSH (left over from old tutorials teaching "force SSH"):

url.git@github.com:.insteadof=https://github.com/

After this rewrite, every https://github.com/... clone actually goes over SSH.

SSH auth uses the account bound to your local SSH key / gh credential helper — when that account is in a bad state (suspended/risk-controlled, key deleted, token expired), even public repos accessible anonymously get rejected.

Secondary source: the gh CLI credential helper injects an expired/suspended token into HTTPS.

url.<new>.insteadOf <old> is git's URL rewriting layer: before any remote access, git checks the rewrite rules in its config and replaces matching addresses wholesale — it works at the "addressing layer", so the command you see is still git clone https://... while the actual transport is SSH.

SSH authentication binds your local SSH key / credential helper to a GitHub account: if the account is banned/rate-limited, the key was removed, or the token expired, authentication fails — even for public repos (public repos are anonymously readable over HTTPS, but SSH demands credentials).

Deterministic takeaway: for a permission error on a public repo, check rewrite rules first (git config --get-all url.*.insteadof) and leftover proxies, then credential state (ssh -T git@github.com, gh auth status);

after unsetting the insteadOf rule, the anonymous HTTPS channel works again — which tells you whether the channel was rewritten or the credential really died.

Step by step

1. Layer the diagnosis first — Diagnose

curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://github.com/

200/301 → network is fine, problem is in git config/credentials; timeout or 000 → network layer (see step 6).

2. Check for rewrite rules — Diagnose

git config --global --get-regexp 'url\..*\.insteadof'

Seeing url.git@github.com:.insteadof https://github.com/ is the culprit.

3. Anonymous HTTPS check (changes nothing, definitive) — Required

GIT_CONFIG_GLOBAL=/dev/null git ls-remote https://github.com/octocat/Hello-World.git

Refs come back → config problem confirmed; if it fails the same way → it's a network/remote problem.

4. Fix: remove the rewrite rule — Required

git config --global --unset-all "url.git@github.com:.insteadof"

Public repos work with anonymous HTTPS. If you genuinely need SSH (private repos/write access), fix the account itself: use a valid SSH key or gh auth login to re-authorize — don't keep a rewrite rule that makes every HTTPS trip.

5. Dirty credentials in the helper — Required

git config --global --list | grep credential
gh auth status

Check for !/usr/bin/gh auth git-credential; if invalid, gh auth logout then gh auth login (public repos need no credentials at all).

6. If step 1 confirms the network layer — Required

Configure a proxy git config --global http.https://github.com.proxy http://127.0.0.1:<port>; or temporarily use an acceleration prefix git clone https://gh-proxy.com/https://github.com/<owner>/<repo>.git (accelerators have a lifecycle;

curl-test before using).

How to confirm it works

Clone succeeds after the fix (measured output shape):

git config --global --unset-all url.git@github.com:.insteadof
git clone --depth 1 https://github.com/octocat/Hello-World.git → exit 0, complete checkout (measured)

Anonymous HTTPS ls-remote returns all refs normally (measured).

Other environments

Symptom

Cloning a public repository (browser can open it, curl works) fails with:

ERROR: Your account is suspended. Please visit https://support.github.com for more information.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Key traits:

• The network is fine: the page opens and curl https://github.com/ returns 200, yet every git command fails (exit 128);
• The error points at "permissions", not "network"; fatal: unable to access ... Timed out is a different (network-layer) family;
• It worked before and broke suddenly, or started after switching machines/accounts;
• The wording is misleading: GitHub returns the exact same "Please make sure you have the correct access rights and the repository exists" for a 403/404 caused by a disabled account — even for public repos.

Cause

Most common: a global git config rewrites HTTPS to SSH (left over from old tutorials that told you to "force SSH"):

url.git@github.com:.insteadof=https://github.com/

After this, every https://github.com/... clone actually goes through git@github.com:... (SSH). SSH auth uses the account bound to your local SSH key / gh credential helper — once that account is disabled (suspended/flagged, key removed, token expired), even public repos that would work anonymously are rejected.

Secondary source: credential.https://github.com.helper=!/usr/bin/gh auth git-credential injects a stale/disabled token into HTTPS requests, producing the same access-rights error.

Solution

1. Layer check first: curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://github.com/ returning 200/301 means the network is fine and the problem is in git config/credentials; timeout or 000 means network layer (see step 6).
2. Find the rewrite: git config --global --get-regexp 'url\..*\.insteadof'. Seeing url.git@github.com:.insteadof https://github.com/ is the smoking gun.
3. Anonymous HTTPS test (changes nothing, settles it):

GIT_CONFIG_GLOBAL=/dev/null git ls-remote https://github.com/octocat/Hello-World.git Returning refs proves it is a config problem; failing the same way means network/remote.

1. Fix: remove the rewrite (public repos work via anonymous HTTPS):

git config --global --unset-all "url.git@github.com:.insteadof" then re-clone to verify. If you genuinely need SSH (private repos/write access), fix the account itself — use a valid SSH key or gh auth login — don't keep a rewrite that makes every HTTPS clone break.

1. Stale credential helper: git config --global --list | grep credential to spot !/usr/bin/gh auth git-credential; gh auth status to check the account, gh auth logout then gh auth login if broken (public repos need no credentials at all).
2. If step 1 confirms a network-layer block (timeout/reset from China): configure a proxy git config --global http.https://github.com.proxy http://127.0.0.1:<port> (http:// or socks5:// both work); or temporarily use an accelerator prefix git clone https://gh-proxy.com/https://github.com/<owner>/<repo>.git — gh-proxy.com / ghfast.top / ghproxy.homeboyc.cn were alive on 2026-08-29 (accelerators have lifespans; curl-test before use).