Skip to main content

git clone git@bitbucket.org:{username}/{repo}.git

And I was unceremoniously delivered the following error

fatal: could not create work tree dir '{project}': Permission denied

My initial thought was the error due to server permission... being sudo.  This was tested by running the command

sudo git clone git@bitbucket.{username}/{repo}.git

Which generated the error

Cloning into 'repo'...
git@bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository.

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

Okay now we have a little more intel.  The error is more likely created by .ssh not being either set-up and/or recognised. 

 

Test SSH authentication

You can troubleshoot SSH authentication issues by testing your SSH authentication.  This command checks your SSH agent for an SSH key, and then checks if that private key matches a public key for an existing Bitbucket account

command response result
ssh -T git@bitbucket.org Permission denied (publickey). You don't have any keys loaded in the agent
ssh -T hg@bitbucket.org  ssh: connect to host bitbucket.org port 22: Connection refused your local machine is unable to get the bitbucket.org IP address
ssh -T hg@bitbucket.org  conq: logged in as name.                 
You can use git or hg to connect to bitbucket. Shell access is disabled. 
success

    
To track down problems with your SSH connection

If you receive a Permission denied (publickey) error, and you've already verified that your key is loaded into your SSH agent and into your Bitbucket account, you can get more information about your connection issues:

 

When I used the following command

ssh -T git@bitbucket.org

which the response did recognise me

Enter passphrase for key '/home/{dir}/.ssh/id_rsa': 
logged in as andrew-fletcher

You can use git to connect to Bitbucket. Shell access is disabled

 

Resolution

This can be caused by a couple of factors, but these are the most common:  That your public key isn't loaded into Bitbucket Cloud

Cross check if your public key is loaded into Bitbucket Cloud by doing:

    Open a browser and log into Bitbucket Cloud.
    Choose Your avatar > Bitbucket settings from the menu bar.

    The system displays the Account settings page.
    Click SSH keys in the Security section.
    The SSH Keys page displays. It shows a list of any existing keys.
    If you do not have any keys listed, follow Set up an SSH key to set one up.

 

SSH key on the server

To create a id_rsa and id_rsa.pub (public) keys on your server, use the following command

ssh-keygen -t rsa -C "username@ip_address"

Entering this command will output something similar to:

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /location/to/your/.ssh/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /location/to/your/.ssh/id_rsa
Your public key has been saved in id_rsa.pub
The key fingerprint is:
SHA256:4LZFWKENLiJdRWiVhKeha91d8JHIpwHbuqzRVDkQW8Vp username@ip_address
The key's randomart image is:
+---[RSA 3072]----+
|o. . .+XX*       |
|.+o...=o*o.      |
|oo.oo++=+.       |
|o +.o+E*         |
| + . *o S        |
|  o * .          |
|   + +           |
|  . o o          |
|     o           |
+----[SHA256]-----+

Note the username@ip_address, will match the one you entered above when you ran the command.

 

id_rsa set-up and added to BitBucket, but the issue persists

git clone git@bitbucket.org:username/repo.git
fatal: could not create work tree dir 'repo': Permission denied

Check the directory ownership is aligned to the username

chown username:group directory

However, this will produce

chown: changing ownership of 'tmp': Operation not permitted

As I didn't add sudo

sudo chown: changing ownership of 'tmp': Operation not permitted

 

Success

git clone git@bitbucket.org:username/repo.git
Cloning into 'repo'...
Enter passphrase for key '/home/username/.ssh/id_rsa': 
remote: Enumerating objects: 121969, done.
remote: Counting objects: 100% (121969/121969), done.
remote: Compressing objects: 100% (68598/68598), done.
remote: Total 121969 (delta 48045), reused 121856 (delta 47989), pack-reused 0
Receiving objects: 100% (121969/121969), 177.39 MiB | 8.63 MiB/s, done.
Resolving deltas: 100% (48045/48045), done.
Updating files: 100% (105676/105676), done.

 

 

Related articles

Andrew Fletcher18 Mar 2024
Resolving CVE-2022-48624 less issue
To resolve the CVE-2022-48624 vulnerability on Ubuntu using Nginx, it's crucial to understand that the issue lies within the "less" package, not Nginx itself. The vulnerability affects "less" before version 606, where close_altfile in filename.c in less omits shell_quote calls for LESSCLOSE,...