Git ssh clone fails with error Permission denied (publickey) in Bitbucket Data Center
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Ssh git clone fails with the following error.
1
2
Permission denied (publickey).
fatal: Could not read from remote repository.In order to get a more detailed output, you can try the command,GIT_SSH_COMMAND="ssh -vvvv" git clone ssh://git@<repository_url>and this will give you the output similar to the below one.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
GIT_SSH_COMMAND="ssh -vvvv" git clone ssh://git@test.bitbucket.com:7999/test/repo.git
15:41:10.964407 git.c:440 trace: built-in: git clone ssh://git@test.bitbucket.com:7999/test/repo.git
Cloning into 'repo'...
...
...
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/frye/.ssh/id_dsa
debug3: no such identity: /home/frye/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/frye/.ssh/id_ecdsa
debug3: no such identity: /home/frye/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/frye/.ssh/id_ed25519
debug3: no such identity: /home/frye/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.Environment
Bitbucket Server/Data Center 7.17.0 or above installed on Ubuntu 14.x LTS or Ubuntu 16.x
Diagnosis
Run ssh localhost from the same machine and retry the clone. It will get successful and you can see the below line in the success output.
1
2
3
4
5
6
7
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:kSWXd+fJmEoWNIFMEa8kIMRjLtCo4vU9DgQJ83JLHP0
debug3: sign_and_send_pubkey: RSA SHA256:kSWXd+fJmEoWNIFMEa8kIMRjLtCo4vU9DgQJ83JLHP0
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to stash.calix.local (via proxy).Cause
When running the clone directly from the client machine, the key is being accessed from the ssh agent gnome-keyring in the Operating system. This is a feature that collects all of your passwords in a secure application (gnome-keyring) and will use these stored passwords to automatically log you in to various services. But it is possible that the passwords stored in the keyring could get outdated and this could cause authentication failures.
To confirm this, you can run the below command twice. Once directly on the machine, then after executing "ssh localhost".
1
echo $SSH_AUTH_SOCKYou can see similar output.
1
2
3
4
5
6
7
$ echo $SSH_AUTH_SOCK
/run/user/10114/keyring/ssh
$ ssh localhost
Last login: Mon Jun 6 18:29:20 2022 from 127.0.0.1
$ echo $SSH_AUTH_SOCK
$The SSH_AUTH_SOCK path variable has been cleared once you run ssh localhost and the key is being taken from the default SSH configuration.
Solution
Please work with your system admin and disable the gnome-keyring: ssh agent in your system(not the server) or you can manually unset the SSH_AUTH_SOCK environment variable.
Was this helpful?