Bits of .NET

🔀 The Same SSH Setup That Worked Yesterday Suddenly Says Permission Denied

git pull or git push over SSH, which worked without any issue yesterday, suddenly fails with ‘Permission denied (publickey)’ today – no changes were made to SSH keys, no new machine, nothing about the local setup was touched, and yet Git refuses to authenticate.

🐞 The Problem

$ git pull origin main
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

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

🔍 Why This Happens

This almost always traces back to something changing on either the
KEY side or the AGENT side, even without deliberate action: an
SSH agent that lost its loaded keys after a reboot or a long sleep
(keys added with ssh-add are often NOT persisted across a restart
unless explicitly configured to be), an expired or revoked deploy
key/access token on the git hosting side, or - less obviously - a
system clock significantly out of sync, which can cause some SSH
key exchange methods to fail validation.

✅ The Fix: Confirm the Agent Actually Has the Key Loaded, Then Check the Remote Side

• Run ssh-add -l to list keys currently loaded in the SSH agent – if it shows ‘The agent has no identities,’ the key was never reloaded after a restart, and simply running ssh-add ~/.ssh/id_ed25519 (or your key’s path) again resolves it immediately.
• Test the connection directly and verbosely: ssh -vT git@github.com – this shows exactly which key (if any) is being offered and why the server rejects it, which is far more informative than Git’s own generic error.
• Check the hosting platform’s SSH key settings (GitHub/GitLab/Bitbucket) to confirm the key hasn’t been removed, expired, or flagged – a key that was valid yesterday can be revoked by an admin, a security policy, or its own configured expiration without any local change at all.

⚠️ Making the Fix Stick Across Reboots

• Configure your SSH client to auto-load keys via a config entry (AddKeysToAgent yes in ~/.ssh/config, or your OS’s keychain integration) so this exact ‘works today, fails after a restart’ cycle stops recurring.
• If multiple keys exist for different services, confirm the right one is actually being offered for this specific host – an SSH config with explicit IdentityFile entries per host avoids ambiguity when several keys are loaded at once.