git clone: "Permission denied (publickey)" — GitHub/GitLab Rejects Your Key

The remote asked for SSH auth and your key didn't work: not loaded, wrong key on the account, or sshd config quirks. Test the exact path with one debug command.

What you'll see

Root causes

Key not offered or not registered on the account

ssh -T git@github.com shows exactly what the server thinks of your keys. If none are offered (agent empty, wrong path in ~/.ssh/config), auth can't happen.

Wrong key file / host entry in ~/.ssh/config

config points github.com at an old key file, or permissions on the key (must be 600) make ssh refuse to use it silently.

Sudo context or non-interactive shells use a different HOME

CI, cron, and sudo run with another HOME: your ~/.ssh never gets read. Use an explicit key path or deploy keys with absolute paths.

Fix it

  1. Test the exact SSH path GitHub/GitLab sees
    ssh -T git@github.com   # 'Hi <user>! You've successfully authenticated' or the failure reason
  2. Check what keys your machine offers
    ssh-add -l ; ls -la ~/.ssh/ ; grep -A3 -i github ~/.ssh/config 2>/dev/null
  3. Fix key permissions (silent killer)
    chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub
  4. Register the pubkey on the platform, or use a scoped deploy key per repo
    cat ~/.ssh/id_ed25519.pub   # paste into GitHub → Settings → SSH keys (or repo → Deploy keys for single-repo access)

Field note

Deploy keys are repo-scoped: prefer them for servers/CI over adding a personal key everywhere. https:// clone with a PAT or credential helper is the pragmatic fallback when SSH is blocked by the network (port 22 filtering).

Common questions

SSH works in my terminal but fails in CI. Why?

CI runs with a different HOME and no ssh-agent. Put the key at an absolute path and reference it explicitly: GIT_SSH_COMMAND='ssh -i /etc/ci/id_ed25519 -o IdentitiesOnly=yes' git fetch...

Can I just use HTTPS instead?

Yes — switch the remote (git remote set-url origin https://github.com/user/repo.git) and use a PAT/credential helper. Slightly less convenient than SSH keys but firewall-friendly.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.