How to Fix SSH “Permission Denied” with Git Clone
Are you frustrated that cloning your Git repository over SSH always results in a “permission denied” error message in the terminal? Here’s how to fix it once and for all.
I operate several droplets on DigitalOcean and this issue has been bugging me for ages. When I couldn’t take it anymore, I spent a whole hour searching for and trying out various suggested fixes with absolutely no avail. Then I reflected on what I was doing in the first place and figured out the logic behind the operations.
Before we start, I wanted to let you know that you can start your own droplet on DigitalOcean with a $100 credit. Simply follow this link:
If you’re not logged in as the root user on your machine, you’ll likely have tried this command to clone your Git repository (GitLab in this case):
sudo git clone git@gitlab.com:PROJECT/REPOSITORY.gitAnd this error keeps re-appearing:
Cloning into 'REPOSITORY'...git@gitlab.com: Permission denied (publickey).
fatal: Could not read from remote repository.Please make sure you have the correct access rights
and the repository exists.
Generate SSH Keys and Test SSH Authentication
First of all, ensure that your SSH key has been generated and the file containing the corresponding public key id_rsa.pub has been added to the account where your Git repository is hosted (scroll below to find a list of Git hosting services and where to add your public key).
If you haven’t generated an SSH key yet, this should be your first step. Run the following command on the machine you plan to Git clone in:
ssh-keygenPress return for all questions by keeping the defaults and empty passphrase. This will generate two files in the ~/.ssh directory within your home directory:
~/.ssh/id_rsa~/.ssh/id_rsa.pub
Copy and paste the content of the newly-generated id_rsa.pub file into the account where your repository is hosted. In my case, this is GitLab.
- GitLab: Navigate to your User Settings > SSH Keys
- GitHub: Navigate to your Settings > SSH and GPG Keys
- BitBucket: Navigate to your Bitbucket settings > SSH keys
Now you can do an SSH authentication test using this command:
ssh -T git@gitlab.comAuthentication should succeed with this return message:
Welcome to GitLab, @mhagemann!Everything should work, but I still cannot clone my Git repository. Argh!
Solution 1: Use HTTPS
This is the most effortless solution at hand. Simply switch to cloning from the HTTPS path for your Git repository. But the convenience of never having to enter your credentials again and letting the SSH keys authenticate you will forever haunt you.
Each git pull will ask for authentication over and over again. That’s not the solution you were looking for. Me neither.
Solution 2: Use ‘sudo git clone’
Move SSH Key Files to root’s .ssh Directory
When performing operations while not logged in with the root user, we are accustomed to precede all commands with sudo. But sudo implies that SSH keys need to be available in the root’s home directory.
This solution is the most elegant because it allows you to continue with the same directory permissions that you had been working with thus far. No radical permission changes will be performed (we’ll get to that in the 3rd solution below).
All you do is move the SSH keys we’ve generated above to the root’s SSH directory located at /root/.ssh. If you try sudo git clone now, you’ll likely encounter this error:
Cloning into 'api'...
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/root/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/root/.ssh/id_rsa": bad permissions
git@gitlab.com: Permission denied (publickey).
fatal: Could not read from remote repository.Please make sure you have the correct access rights
and the repository exists.
While this warning won’t let you proceed any further, there is a simple fix to it. Set the file permissions to 600 (owner read-write) and retry sudo git clone.
It should work now.
Solution 3: Use ‘git clone’ (without sudo)
Amend Permissions of the Target Directory
This solution requires a change of file permissions for entire directories. As it’s quite intrusive, this isn’t my favorite option.
You can actually git clone without the sudo, but will probably run into writing permission errors like these:
fatal: could not create work tree dir 'api': Permission deniedA workaround is to amend the target’s directory permissions so that your non-root user can clone the necessary files into it. I followed a simple tutorial to correct permissions on /var/www:
- Change the directory owner and group:
sudo chown www-data:www-data /var/www - Allow the group to write to the directory with appropriate permissions:
sudo chmod -R 775 /var/www - Add yourself to the www-data group:
sudo usermod -a -G www-data USER
Replace USER with your account’s user name. That’s it. You should now be able to clone into the desired directory under /var/www.
Conclusion
I hope either one of three solutions suggested above will help you in fixing the persistent permission errors. It’s just a matter of using common sense: SSH-ing with the superuser command means that SSH will look for keys in the root’s home directory.
Not using the superuser command is generally unconventional. At least it will look up SSH keys in your home directory, but requires appropriate directory writing permissions.
