When Git Slams the Door
You've finally finished a tough feature, hit git push, and instead of seeing your code go live, your terminal hits you with a blunt rejection. The process stops dead with a wall of text ending in:
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
This isn't a bug in your code. It's an authentication wall. GitHub (or GitLab/Bitbucket) simply doesn't recognize your computer. Usually, the culprit is a missing key, a typo in your remote URL, or local file permissions that are far too loose.
First: Test Your Connection
Before you start regenerating keys, check if you actually have a connection to the provider. Run this command to see how GitHub sees you:
ssh -T git@github.com
If you see a success message like "Hi username! You've successfully authenticated...", your key is working. The issue is likely a typo in your remote URL. If the terminal repeats Permission denied (publickey), keep reading.
Step 1: Look for Existing Keys
Many developers already have a key but aren't using the right filename. List your .ssh directory to see what is currently there:
ls -al ~/.ssh
Check for files like id_ed25519.pub or id_rsa.pub. If your directory is empty or missing files ending in .pub, you need to create a new pair.
Step 2: Generate a Modern SSH Key
If you're starting fresh, generate an Ed25519 key. These are faster, more secure, and much shorter (around 68 characters) than older RSA keys.
ssh-keygen -t ed25519 -C "your_email@example.com"
When the terminal asks where to save the key, press Enter to accept the default path. You can add a passphrase for extra security, though many developers leave it empty for a smoother workflow.
Step 3: Register the Key with Your Provider
Now you must tell the server about your public key. Be careful: never share your private key (the one without the .pub extension).
Copy the public key content to your clipboard:
# macOS
pbcopy `git remote set-url origin git@github.com:user/repo.git`
- **WSL Complexity:** If you use Windows Subsystem for Linux, remember that your keys inside Linux are separate from your keys in Windows PowerShell. You usually need to pick one environment and stick to it.
## Summary
Fixing `Permission denied (publickey)` usually comes down to three things: having a valid key, telling the server about it, and keeping your local permissions tight. Once your `ssh -T` test returns a greeting, you can get back to shipping code without the authentication headaches.