You’ve got a repository URL, you’ve opened your terminal, and you’ve typed what should be a simple command:
git clone git@github.com:USERNAME/REPO.gitAnd then this comes back:
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.
Or maybe you tried HTTPS and got this instead:
remote: Repository not found.
fatal: repository 'https://github.com/USERNAME/REPO.git/' not foundOr this:
fatal: Authentication failed for 'https://github.com/USERNAME/REPO.git/'Whatever variation you’re seeing, the result is the same — the repository didn’t clone, and Git is being frustratingly vague about why.
Here’s the thing: git clone is one of the most basic Git operations there is. It shouldn’t be failing. But when it does, it’s almost always because of one of six well-defined causes — and every single one of them has a clean, tested fix.
This guide covers both SSH and HTTPS cloning, works across GitHub, GitLab, and Bitbucket, and walks you through each fix with the exact commands you need. No fluff, no vague suggestions. Just the diagnosis and the solution.
Let’s get into it.
Git Clone Permission Denied Error – 6 Quick Fixes (SSH & HTTPS Guide)
What Is the Git Clone Permission Denied Error?
The git clone permission denied error is a catch-all term for a family of errors that appear when you try to clone a repository and Git can’t complete the authentication or authorization step. You’ve told Git where the repository is, but something about your identity — or Git’s ability to prove it — failed.
Here are the most common variations you’ll see depending on your setup:
SSH-based clone errors:
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.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.ssh: connect to host github.com port 22: Connection refused
fatal: Could not read from remote repository.HTTPS-based clone errors:
remote: Repository not found.
fatal: repository 'https://github.com/USERNAME/REPO.git/' not foundfatal: Authentication failed for 'https://github.com/USERNAME/REPO.git/'remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/USERNAME/REPO.git/'error: 403 while accessing 'https://github.com/USERNAME/REPO.git/'All of these are telling you one of two things: either Git can’t prove who you are (authentication failure), or Git knows who you are but you don’t have access to that repository (authorization failure). The fix depends entirely on which one is happening and whether you’re using SSH or HTTPS.
Before we get into the individual fixes, let’s look at the full picture of why this happens.
Why Does Git Clone Fail With Permission Denied?
Understanding the root cause makes the fix obvious. There are six main reasons git clone fails with a permission denied or authentication error.
Reason 1 — No SSH Key or an Unregistered SSH Key (SSH Cloning)
SSH cloning relies on a cryptographic key pair. Your machine holds the private key, and GitHub holds the matching public key. When you clone over SSH, your machine presents the private key as proof of identity. If you’ve never generated an SSH key, or if you have a key locally but never added the public half to your GitHub account, the handshake fails and you get “Permission denied (publickey).”
This is the single most common cause of the SSH clone error, especially on new machines or fresh OS installs.
Reason 2 — SSH Agent Not Running or Key Not Loaded
Even if your key files exist and are registered on GitHub, SSH needs the agent to be running and holding the key in memory. After a reboot, a new terminal session, or a logout, the SSH agent often starts empty. The key files are on disk but the agent isn’t presenting them, so the authentication fails exactly as if no key existed.
Reason 3 — Wrong Remote URL Protocol
When you copy a clone URL from GitHub, there are three options: HTTPS, SSH, and GitHub CLI. If you grab the HTTPS URL and try to use SSH key authentication, or grab the SSH URL when you haven’t set up SSH keys, the mismatch causes the error. This sounds obvious in hindsight but catches people constantly — especially when URLs are shared by teammates who use a different authentication method.
Reason 4 — Expired, Wrong, or Missing HTTPS Credentials
If you’re cloning over HTTPS, Git authenticates with a username and personal access token (not your account password — GitHub removed password authentication in August 2021). If your token expired, if you’ve never set one up, if the wrong credentials are cached in your OS credential manager, or if you accidentally entered your account password instead of a token, cloning will fail.
Reason 5 — No Access to the Repository
This one is authorization rather than authentication. Your credentials are fine, but your GitHub account simply doesn’t have permission to access the repository you’re trying to clone. This happens with private repositories where you haven’t been added as a collaborator, organization repositories where your membership hasn’t been set up correctly, or repositories that have been made private after you last accessed them.
Reason 6 — File System Permission Issues (Local Directory)
Less obvious than the others, but worth knowing: if the directory you’re cloning into doesn’t allow your user to write files, git clone will fail with a permission denied error that has nothing to do with GitHub. This is common in shared hosting environments, Docker containers, or when cloning into system directories.
Now let’s fix each of these.
Fix 1 — Set Up or Re-Register Your SSH Key
This is the fix for the SSH clone error when you either don’t have an SSH key or haven’t added it to GitHub yet. It’s the most comprehensive fix in this guide, but it only needs to be done once per machine.
Step 1 — Check If an SSH Key Already Exists
ls -al ~/.ssh
Look for files named id_ed25519 and id_ed25519.pub, or id_rsa and id_rsa.pub. If you see these pairs, your key exists — jump to Step 3 to check if it’s registered on GitHub. If the ~/.ssh directory is empty, doesn’t exist, or only contains known_hosts and config, you need to generate a new key.
Step 2 — Generate a New SSH Key
Use Ed25519 — it’s the current standard, faster and more secure than RSA:
ssh-keygen -t ed25519 -C “you@example.com”
Replace the email with the one attached to your GitHub account. When prompted for a file location, press Enter to accept the default. Optionally set a passphrase — recommended for security, and easy to automate later with the SSH agent.
If you’re on an older system that doesn’t support Ed25519:
ssh-keygen -t rsa -b 4096 -C “you@example.com”
This creates two files: ~/.ssh/id_ed25519 (private key — never share this) and ~/.ssh/id_ed25519.pub (public key — this goes to GitHub).
Step 3 — Add the Key to Your SSH Agent
eval “$(ssh-agent -s)”
ssh-add ~/.ssh/id_ed25519
You should see:
Agent pid 12345
Identity added: /home/user/.ssh/id_ed25519 (you@example.com)
Step 4 — Copy Your Public Key
macOS:
pbcopy < ~/.ssh/id_ed25519.pub
Linux:
xclip -sel clip < ~/.ssh/id_ed25519.pub
If xclip isn’t available:
cat ~/.ssh/id_ed25519.pub
(Copy the output manually)
Windows (Git Bash):
clip < ~/.ssh/id_ed25519.pub
Step 5 — Add the Public Key to GitHub
Go to GitHub → Settings → SSH and GPG keys → New SSH key. Give it a recognizable name like “Personal Laptop 2025,” paste the public key you copied, and click Add SSH key.
For GitLab: User Settings → SSH Keys
For Bitbucket: Personal settings → SSH keys
Step 6 — Verify the Connection
ssh -T git@github.com
Expected output:
Hi yourusername! You’ve successfully authenticated, but GitHub does not provide shell access.
Once this works, retry git clone — it will go through.
Fix 2 — Reload the SSH Agent and Key
This fix is for when your SSH key exists and is already registered on GitHub, but cloning still fails. The most likely culprit is that the SSH agent started fresh (after a reboot or new terminal session) and no longer has your key loaded.
Check whether the agent has any keys loaded:
ssh-add -l
If you see:
The agent has no identities.
That’s the problem. Reload your key:
eval “$(ssh-agent -s)”
ssh-add ~/.ssh/id_ed25519
If you set a passphrase on your key, you’ll be prompted to enter it here. After loading the key, verify the connection:
ssh -T git@github.com
Then retry the clone.
To prevent this from happening every time you open a new terminal, set up your SSH config file so the agent loads the key automatically. Create or edit ~/.ssh/config and add:
Host github.com
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
On macOS, add UseKeychain yes to store the passphrase in Keychain so you never need to type it again:
Host github.com
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519
After saving this file, the key will load automatically whenever SSH needs it — no manual ssh-add required.
Fix 3 — Use the Right Clone URL for Your Authentication Method
This fix addresses Reason 3 — a mismatch between the clone URL format and your authentication method. The URL you use to clone determines which authentication method Git uses, and picking the wrong one causes the permission denied error immediately.
Check which URL format you’re using:
SSH URL format:
git@github.com:USERNAME/REPO.git
HTTPS URL format:
https://github.com/USERNAME/REPO.git
GitHub CLI format:
gh repo clone USERNAME/REPO
If you have SSH keys set up and want to clone over SSH, use the SSH URL. If you don’t have SSH keys set up and want to clone over HTTPS, use the HTTPS URL.
The error happens when you use an SSH URL without SSH keys set up, or when you’re in an environment where SSH is blocked and you need HTTPS.
To switch from one to the other during an active clone attempt, just stop and re-run the command with the correct URL:
For SSH:
git clone git@github.com:USERNAME/REPO.git
For HTTPS:
git clone https://github.com/USERNAME/REPO.git
On GitHub, when you click the green Code button on a repository page, you’ll see a small toggle at the top of the dropdown that switches between HTTPS, SSH, and GitHub CLI. Select the one that matches your setup before copying the URL.
On GitLab, the Clone button shows “Clone with SSH” and “Clone with HTTPS” as separate options.
On Bitbucket, the Clone button dropdown has the same SSH and HTTPS split.
A quick rule of thumb: if you’ve completed Fix 1 and have SSH working, always use SSH URLs. They’re more reliable long-term because they don’t require token management. If you haven’t set up SSH keys or you’re in a restricted environment, use HTTPS.
Fix 4 — Fix HTTPS Authentication With a Personal Access Token
This fix covers the HTTPS version of the clone error — “Authentication failed,” “Invalid username or password,” or “Repository not found” when cloning over HTTPS.
Since GitHub deprecated account password authentication for Git operations in August 2021, you must use a personal access token (PAT) as your password when cloning over HTTPS. GitLab and Bitbucket have similar requirements.
Generate a Personal Access Token on GitHub
Go to GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token.
Give it a descriptive name, set an expiry date (90 days or 1 year for personal use), and under Scopes select repo. This gives the token access to clone, pull, and push to your repositories. Click Generate token and copy it immediately — GitHub only shows it once.
Generate a Personal Access Token on GitLab
Go to User Settings → Access tokens. Set a name, expiry date, and select read_repository and write_repository scopes (or api for full access). Click Create personal access token and copy the result.
Generate a Personal Access Token on Bitbucket
Go to Personal settings → App passwords → Create app password. Give it a label, select the Repositories read and write permissions, and click Create. Copy the generated password.
Clone Using the Token
Once you have a token, use it directly in the clone command by embedding it in the URL:
git clone https://TOKEN@github.com/USERNAME/REPO.git
Replace TOKEN with your actual token value, USERNAME with your GitHub username, and REPO with the repository name.
Alternatively, run the standard clone command and paste the token when Git prompts for a password:
git clone https://github.com/USERNAME/REPO.git
Username: your-github-username
Password: [paste token here]
Set Up Credential Caching
To avoid pasting the token on every git clone and every subsequent push/pull, configure your OS credential manager:
macOS:
git config –global credential.helper osxkeychain
Windows:
git config –global credential.helper manager
Linux:
git config –global credential.helper ‘cache –timeout=3600’
After setting this, the first time you authenticate successfully, your OS stores the token and uses it automatically for every subsequent operation.
Clear Stale Cached Credentials If Needed
If you previously had credentials stored and they’re now expired or wrong, Git will keep sending the old ones without prompting you. Clear them first:
macOS:
git credential-osxkeychain erase
host=github.com
protocol=https
[press Enter twice]
Windows (in Git Bash or Command Prompt):
git credential reject
host=github.com
protocol=https
[press Enter twice]
Or open Windows Credential Manager, find the github.com entry, and delete it manually.
After clearing, retry the clone and enter your username and fresh token when prompted.
Fix 5 — Fix Repository Access and Permissions
This fix covers the case where your authentication is working correctly, but the repository itself is refusing access. The error looks the same — “Permission denied” or “Repository not found” — but the cause is different.
First, confirm your authentication is working at all:
ssh -T git@github.com
If this returns “Hi username! You’ve successfully authenticated,” the problem isn’t your SSH setup. It’s your access to the specific repository.
Here are the most common access-related causes and fixes:
You Haven’t Been Added as a Collaborator
For private repositories, the owner needs to explicitly add you as a collaborator. Go to the repository on GitHub, click Settings → Collaborators and teams, and ask the owner to add your GitHub username.
If you’re the owner, go to the repository settings and confirm that the person trying to clone has been invited and accepted the invitation.
You Haven’t Accepted a Collaboration Invitation
GitHub sends an email invitation when someone adds you as a collaborator. If you haven’t accepted it, you won’t have access even though the owner added you. Check your email for a GitHub invitation, or go to github.com/notifications and look for pending invitations.
Organization Repository Access
If the repository belongs to a GitHub organization, your personal access token needs to be authorized for that organization. Go to GitHub → Settings → Developer settings → Personal access tokens, find your token, and click Configure SSO (if the organization uses SAML SSO). Authorize the token for the organization.
Similarly, if you joined the organization but haven’t confirmed your membership, go to the organization’s page and accept the membership. Unconfirmed organization members don’t get repository access.
SSH Key Not Authorized for an Organization With SSO
If the organization uses SAML single sign-on, your SSH key needs to be explicitly authorized. Go to GitHub → Settings → SSH and GPG keys, find the key you’re using, and click Authorize next to the organization name. This step is separate from adding the key to your account and is easy to miss.
Trying to Clone Someone Else’s Private Repository
You can’t clone a private repository that you haven’t been granted access to, regardless of how good your SSH setup is. Private repositories are private. If you believe you should have access, contact the repository owner.
Forking Instead of Cloning
If you want to work with someone else’s repository without having direct access, fork it first (click Fork on the repository page), then clone your fork:
git clone git@github.com:YOUR-USERNAME/REPO.git
Your fork is a full copy under your own account, so you have complete access to it.
Fix 6 — Fix Local File System Permission Issues
This fix covers the less obvious scenario where the “permission denied” error has nothing to do with GitHub at all — it’s your local file system refusing to let Git write files. This happens more often than people expect, particularly in containerized environments, shared hosting, and systems where directories are owned by different users.
The error looks subtly different in this case:
fatal: could not create work tree dir ‘REPO’: Permission denied
or:
error: cannot mkdir REPO: Permission denied
Notice it says “could not create work tree dir” or “cannot mkdir” — these are local file system errors, not remote authentication errors.
Check the Directory Permissions
Navigate to where you’re trying to clone:
ls -la
Look at the permissions and owner of the target directory. If the directory is owned by root or another user, your current user can’t write to it.
Fix Option 1 — Clone Into a Directory You Own
The simplest fix is to clone into a directory where your user has write access:
cd ~
git clone git@github.com:USERNAME/REPO.git
Cloning into your home directory always works because you own it.
Fix Option 2 — Fix the Directory Ownership
If you need to clone into a specific directory, fix its ownership:
sudo chown -R $(whoami) /path/to/target/directory
This changes the ownership of the target directory to your current user. After running this, retry the clone.
Fix Option 3 — Fix the Directory Permissions
If ownership is correct but permissions are wrong:
sudo chmod 755 /path/to/target/directory
This gives your user read, write, and execute access to the directory.
Docker and Container Environments
In Docker containers, the user running git clone is often different from the user who owns the mounted volume. This is a common pain point in development containers and CI/CD Docker images.
The typical fix is to ensure the container runs as the same user as the directory owner:
docker run –user $(id -u):$(id -g) -v $(pwd):/workspace IMAGE git clone …
Or fix the permissions on the mounted volume before cloning.
Shared Hosting Environments
On shared hosting (cPanel, Plesk, etc.), you typically don’t have sudo access. Work within directories your hosting account owns — usually everything under /home/youraccount/. Cloning into system directories or other account directories will fail with permission denied.
Real Terminal Example — Full Diagnosis and Fix
Here’s a complete diagnostic session showing how to identify the problem and apply the right fix. This example is on a Linux machine where the SSH agent had lost its key after a reboot:
$ git clone git@github.com:devuser/my-project.git
Cloning into ‘my-project’…
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.
$ ssh -T git@github.com
git@github.com: Permission denied (publickey).
[Confirms SSH is the issue, not repository permissions]
$ ls -al ~/.ssh
total 16
drwx—— 2 user user 4096 Mar 27 09:15 .
drwxr-xr-x 8 user user 4096 Mar 27 09:00 ..
-rw——- 1 user user 411 Mar 26 18:30 id_ed25519
-rw-r–r– 1 user user 98 Mar 26 18:30 id_ed25519.pub
[Key files exist — agent must not have them loaded]
$ ssh-add -l
The agent has no identities.
[Confirmed — agent is empty]
$ eval “$(ssh-agent -s)”
Agent pid 14782
$ ssh-add ~/.ssh/id_ed25519
Identity added: /home/user/.ssh/id_ed25519 (dev@example.com)
$ ssh -T git@github.com
Hi devuser! You’ve successfully authenticated, but GitHub does not provide shell access.
[Authentication working]
$ git clone git@github.com:devuser/my-project.git
Cloning into ‘my-project’…
remote: Enumerating objects: 127, done.
remote: Counting objects: 100% (127/127), done.
remote: Compressing objects: 100% (84/84), done.
remote: Total 127 (delta 38), reused 115 (delta 29), pack-reused 0
Receiving objects: 100% (127/127), 48.32 KiB | 2.87 MiB/s, done.
Resolving deltas: 100% (38/38), done.
[Clone successful]
$ cat ~/.ssh/config
[File doesn’t exist yet — adding it to prevent future recurrence]
$ nano ~/.ssh/config
[Added the following and saved:]
Host github.com
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
[Now the key loads automatically on every new session]
Prevention Tips — How to Avoid This Error Going Forward
Getting the clone working is the immediate goal. Staying out of this situation permanently is the longer-term one. Here are the habits that make git clone just work, every time.
Tip 1 — Always Configure the SSH Config File After Setting Up Keys
The single most effective prevention measure. After generating and registering your SSH key, immediately create or edit ~/.ssh/config and add the Host github.com block with AddKeysToAgent yes and your IdentityFile path. Once this is in place, you never have to manually run ssh-add again — SSH handles it automatically whenever it needs the key.
Tip 2 — Test SSH Before You Need to Clone
After setting up a new machine, run ssh -T git@github.com right away — before you open any projects or try to clone anything. If it works, you’re good. If it fails, you can fix it in a clean mental state rather than mid-project. The same applies after a major OS update or anything that might have touched your ~/.ssh directory.
Tip 3 — Use SSH URLs for All Long-Term Work
HTTPS clone URLs work, but they require token management — tokens expire, credentials get stale, and OS credential managers occasionally lose stored tokens. SSH keys, once configured, work indefinitely on the same machine. Make it a habit to always select the SSH tab when copying clone URLs from GitHub.
If you have an existing repository cloned with HTTPS that you want to switch to SSH:
git remote set-url origin git@github.com:USERNAME/REPO.git
Tip 4 — Set a Token Expiry Calendar Reminder for HTTPS Users
If you prefer HTTPS authentication, tokens with expiry dates are more secure than tokens that never expire. Set a calendar reminder one week before your token expires to regenerate it and update your credential manager. A two-minute task that prevents a surprise mid-project lockout.
Tip 5 — Name Your SSH Keys Clearly on GitHub
Go to GitHub → Settings → SSH and GPG keys and review your registered keys. Give each key a name that clearly identifies which machine it belongs to — “Work MacBook Pro March 2025,” not just “key.” When you retire a machine, delete its key from GitHub immediately. Unused keys sitting in your GitHub account are a security risk.
Tip 6 — Verify Access to Private Repositories Before You Need Them
Before a project kicks off, verify that everyone who needs to clone a private repository has actually accepted their collaboration invitation and tested access. A quick ssh -T git@github.com from each team member’s machine takes 30 seconds and saves the conversation where someone is blocked on their first day.
Tip 7 — Use Deploy Keys for Automated Environments
For CI/CD pipelines, servers, or any automated system that needs to clone repositories, don’t use a personal SSH key or a personal access token tied to your account. Use deploy keys — SSH keys registered specifically to a repository with read-only (or read-write) access. Go to Repository → Settings → Deploy keys → Add deploy key. This scopes access precisely, doesn’t affect your personal account if the key is compromised, and doesn’t break if you change your password or rotate your personal tokens.
FAQ
Q: Why does git clone say “repository not found” for a repository I can see on GitHub?
“Repository not found” is GitHub’s generic error for both “this repo doesn’t exist” and “this repo exists but you don’t have access.” If you can see the repository when logged into GitHub in your browser, but git clone says it’s not found, it almost always means your Git credentials aren’t matching the right account, or the credentials aren’t being sent at all. Run ssh -T git@github.com to confirm which account your SSH key authenticates as, and compare it to the account that has access.
Q: Can I clone a public repository without any authentication setup?
Yes. Public repositories can be cloned over HTTPS without any credentials at all:
git clone https://github.com/USERNAME/REPO.git
No SSH keys, no tokens, no login required. The permission denied error only appears for private repositories or when using SSH URLs (which require key authentication even for public repos in some configurations).
Q: I get “Permission denied (publickey)” even though I can push and pull fine from other repositories. Why?
The most likely explanation is that this specific repository belongs to an organization that uses SAML SSO, and your SSH key hasn’t been authorized for that organization. Go to GitHub → Settings → SSH and GPG keys, find your key, and look for an Authorize button next to the organization name. Click it and complete the SSO authorization. After that, cloning from organization repositories will work.
Q: Why does my SSH clone work on the command line but fail in my IDE?
IDEs like VS Code, IntelliJ, and others sometimes run Git with a different environment than your terminal — one where the SSH agent isn’t accessible or where the SSH config file isn’t loaded. Try running the clone from the terminal first to confirm it works. If the terminal works but the IDE doesn’t, check the IDE’s Git settings to ensure it’s using the same SSH executable and config as your terminal. In VS Code, the Remote SSH extension has its own SSH handling that sometimes needs separate configuration.
Q: How do I clone a repository when port 22 is blocked by my corporate firewall?
GitHub supports SSH connections over port 443, which corporate firewalls almost never block. Add this to your ~/.ssh/config:
Host github.com
Hostname ssh.github.com
Port 443
User git
IdentityFile ~/.ssh/id_ed25519
After saving, test with ssh -T git@github.com and then retry your clone. The connection will route through port 443 instead of 22.
Q: I’m on Windows and getting “Permission denied (publickey)” — is the fix different?
The steps are essentially the same on Windows, but the tools differ slightly. Use Git Bash (not Command Prompt or PowerShell, unless you’ve specifically configured SSH there) to run the ssh-keygen, ssh-add, and ssh -T commands. Git Bash ships with its own SSH client that integrates with Git for Windows. One Windows-specific issue: if your user profile path contains spaces (e.g., C:\Users\John Smith.ssh), some SSH versions have trouble finding the key files. The fix is to use the Windows OpenSSH agent instead of the Git Bash agent. Open Windows Settings → Apps → Optional Features and enable OpenSSH Client, then use Windows Services to start the OpenSSH Authentication Agent.
Q: Can I have multiple SSH keys for different GitHub accounts?
Yes, and this is a common need for developers who have both a personal GitHub account and a work GitHub account. Use the SSH config file to map different hostnames to different keys:
Host github.com-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
Host github.com-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
When cloning, use the custom hostname instead of github.com:
git clone git@github.com-personal:personal-username/REPO.git
git clone git@github.com-work:work-org/REPO.git
This routes each connection to the correct key automatically.
Q: What does “WARNING: UNPROTECTED PRIVATE KEY FILE” mean during a clone?
It means your private key file has permissions that are too open — other users on the system can read it. SSH refuses to use an insecure key file. Fix the permissions:
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh
The private key file should be readable only by your user (600), and the .ssh directory itself should also be restricted (700). After fixing permissions, the warning will disappear and SSH will use the key normally.
Q: I cloned successfully once but now the same command fails. What changed?
The most common causes: your personal access token expired (HTTPS), your SSH agent lost the key after a reboot (SSH), someone removed you as a collaborator or the repository was made private, or your organization revoked your access. Start with ssh -T git@github.com to check SSH, then check your token status on GitHub, and then verify you still have access to the repository through the GitHub web interface.
Q: Is it better to clone with SSH or HTTPS?
For regular development work on your own machine, SSH is generally better. Once configured, it works indefinitely without token management or credential expiry to worry about. HTTPS is simpler to set up initially and works better in environments where SSH is blocked (corporate networks, some cloud environments). For CI/CD and deployment scripts, HTTPS with tokens or deploy keys are both valid depending on your security requirements.
Related Errors
These errors often appear in the same context as the clone permission denied error, either before it, after it, or as a result of the same underlying misconfiguration.
git@github.com: Permission denied (publickey) — on push or pull
The same SSH authentication error, but appearing during push or pull rather than clone. The fix is identical to Fix 1 and Fix 2 in this guide. The error shows up on any Git operation that requires SSH authentication, not just clone.
fatal: Authentication failed for ‘https://…’ — on push or pull
The HTTPS authentication error on push or pull rather than clone. Fix 4 in this guide applies. The most common cause in this context is a recently expired personal access token.
remote: Support for password authentication was removed
GitHub’s specific message when you try to use your account password (instead of a personal access token) for HTTPS authentication. The fix is to generate a personal access token and use that as the password. See Fix 4.
error: The requested URL returned error: 403
A 403 error means authentication worked but authorization failed. You’re known to the server, but you don’t have permission to perform the requested action. Check your repository collaborator status and the scopes on your personal access token. For SSH, check whether you need to authorize the key for an SSO organization.
Host key verification failed
GitHub’s host key fingerprint doesn’t match what’s stored in your ~/.ssh/known_hosts file. This happens after GitHub rotates its host keys, or on a new machine connecting to GitHub for the first time when something goes wrong during the initial confirmation. Fix it:
ssh-keyscan github.com >> ~/.ssh/known_hosts
fatal: destination path ‘REPO’ already exists
Not a permission error, but commonly hits people right after fixing the permission denied error when they retry the clone without noticing Git created a partial directory. Delete the partial clone directory and retry:
rm -rf REPO
git clone git@github.com:USERNAME/REPO.git
fatal: unable to access ‘https://…’: SSL certificate problem
A TLS certificate verification failure, common on corporate networks with SSL inspection proxies. Not an authentication error, but often appears alongside credential issues. Talk to your network team, or as a temporary workaround on a trusted network:
git config –global http.sslVerify false
Conclusion
The git clone permission denied error is frustrating precisely because it blocks you at the very first step — before you’ve even started working. But every variation of this error comes down to the same question: can Git prove your identity to the remote server, and does that identity have access to the repository?
For SSH clones, the answer almost always lies in one of three places: the key doesn’t exist yet (Fix 1), the key exists but the agent isn’t presenting it (Fix 2), or the wrong URL format was used (Fix 3). Setting up the ~/.ssh/config file with AddKeysToAgent yes after the initial setup is the single best thing you can do to prevent SSH-related clone errors from ever coming back.
For HTTPS clones, the answer is almost always about credentials. Since GitHub and GitLab deprecated password authentication, personal access tokens are the required replacement. Once you have a valid token and a credential manager configured to cache it, HTTPS cloning is just as seamless as SSH.
And if neither of those applies, check your repository access (Fix 5) and your local file system permissions (Fix 6) — they’re less common causes but account for a meaningful slice of clone errors, especially in team environments and automated setups.
The diagnostic shortcut throughout all of this is ssh -T git@github.com. Run that first. If it says “Hi username! You’ve successfully authenticated,” every SSH-related cause is eliminated and you can focus entirely on credentials, URLs, and access. If it returns “Permission denied (publickey),” start from Fix 1 and work through the SSH setup.
Clone errors feel like a wall. But it’s a wall with a door in it — and you now have all six keys.
Related Resources
GitHub Docs — Connecting to GitHub with SSH
GitHub Docs — Generating a new SSH key and adding it to the ssh-agent
Github Blogs – Collection of blog articles on git and github
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.