Fix Git permission denied (publickey)
Confirm the SSH host, loaded key, account authorization, and repository access without exposing private keys or disabling host verification.
Permission denied (publickey) means the SSH server did not accept any offered identity. The cause may be the wrong host or account, a key that is not loaded, a public key not registered with the provider, or missing repository authorization.
Verify the remote and host
git remote -v
ssh -T git@github.comUse the host from your actual remote; GitLab and self-hosted services have different domains. A successful authentication test may still say shell access is unavailable—that can be normal for a Git hosting service.
For diagnosis, verbose SSH output shows which identities are offered:
ssh -vT git@github.comReview the filenames and server responses, but do not publish the complete debug log without checking it for usernames and paths.
Check the agent safely
ssh-add -lIf no identities are loaded, add the exact private key through your operating system’s SSH agent. Never paste a private key into a repository, website, issue, or chat. Only the public key (usually the .pub file) belongs in the hosting account’s SSH key settings.
Multiple accounts need explicit configuration
When two accounts use the same hosting domain, define distinct host aliases in ~/.ssh/config, each with its intended IdentityFile, then use that alias in the Git remote. Keep the configuration file readable only by your user where the platform requires it.
Do not disable TLS or SSH host-key verification as a workaround. Confirm the server fingerprint through the provider’s official documentation. If SSH policy remains inconvenient, HTTPS vs. SSH for Git explains the alternative.