git@github.com: Permission denied (publickey) during a GitHub incident, with the SSH key still registered
Unattended git pushes began failing with "Permission denied (publickey)" about ten minutes before GitHub opened an incident covering Git Operations. The key was unchanged and still listed on the account, and the same key authenticated once between failures. The error alone does not show that a key was removed; check the public key list and the status API before rotating anything.
What was seen
On 2026-11-04, cron jobs pushing over SSH started failing:
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Failures began around 09:40 UTC. GitHub opened an incident for Git Operations, Issues and Pull Requests at 09:49 UTC, with one push in between rejected as ! [remote rejected] main -> main (Internal Server Error).
Over the next 90 minutes, with the same key and no local change:
ssh -vshowed the key being offered and refused, against GitHub's correct host key.- One
ssh -T git@github.comsucceeded at about 11:01 UTC. - Three more attempts at about 11:04 UTC failed again.
The incident was still open at the time of writing, so full recovery was not yet observed. The timing and the one success point to GitHub's side, but GitHub's incident text does not name SSH authentication specifically.
Checks before suspecting the key
-
Compare fingerprints. The public key list needs no token:
curl -s https://github.com/<user>.keys | ssh-keygen -lf - ssh-keygen -lf ~/.ssh/id_ed25519.pub -
Read open incidents:
curl -s https://www.githubstatus.com/api/v2/incidents/unresolved.json -
Retry
ssh -T git@github.coma few times. A single success with an unchanged key means the key is still valid.
gh ssh-key list is not a reliable check here: without the admin:public_key scope it fails with HTTP 404, which can look like a missing key.
Practical consequence
Don't rotate keys or edit SSH config because of this error alone. Jobs that push once a day leave their commit local until a later successful run, so a retry after the incident closes is enough. Jobs that report any failed push may raise a false alarm about the key.
Conditions
- openssh
- 9.6p1
- os
- Ubuntu 24.04
- observed
- 2026-11-04
- auth
- user-level ed25519 SSH key
Sources
- GitHub status API, unresolved incidents — Listed 'Incident with Pull Requests, Git Operations and Issues', created 2026-11-04T09:49:55Z, while the failures were happening. The endpoint is live, so it only shows incidents open at the time of the request.