Troubleshoot SSH Issues

If you are having problems with SSH, here are some things you can try when troubleshooting your issues. 

Specific Error Messages

Permission denied (publickey) or No suitable response from remote

When attempting to clone, push or pull over SSH with Git or Mercurial, you receive the message:

Permission denied (publickey).

OR

remote: Permission denied (publickey).
abort: no suitable response from remote hg! 

You are receiving this message because Bitbucket Cloud could not authenticate you with any of the keys that were offered to it by your SSH agent.  To verify this is the case, do the following:

Git Mercurial
ssh -Tv git@bitbucket.org
ssh -Tv hg@bitbucket.org

The command tests your connection to Bitbucket as a Git or Mercurial user. It first sees if your SSH Agent has an identity loaded. The command then checks if that private key matches a public key for an existing Bitbucket account. You might have either problem.

The permission denied message can be caused by a couple of factors, but these are the most common.

Your public key isn't loaded into Bitbucket

To check to see if your public key is loaded into Bitbucket, do the following:

  1. Open a browser and log into Bitbucket.
  2. Choose  Username > Account from the menu bar. 
    The system displays the Account settings page.
  3. Click SSH keys.
    The SSH Keys page displays. It shows a list of any existing keys.
  4. If you do not have any keys listed, follow Add an SSH key to an account to set one up.

Your identity isn't loaded into your SSH Agent

If your SSH agent doesn't know to offer Bitbucket a key, the connection will fail. To find out what keys your SSH Agent currently is offering, and add them, do the following:

On GitBash, OSX, or Linux
$ ssh-add -l

Then, if you don't see your key listed, add it by 

$ ssh-add ~/.ssh/identity

On Windows using Pageant

Double-click Pageant to view loaded keys

Click Add Key to add any key not found in the list

You used sudo when attempting the connection

You do not need to use sudo when cloning a repository or any other SSH action with Bitbucket.

Could not open a connection to your authentication agent

You may see this error when trying to use the ssh-add command. Most likely your ssh-agent was not started properly. To start the agent in the GitBash shell, run the following

$ eval `ssh-agent`
Agent pid 9700

Then, use the ssh-add command to add your identities.

.bashrc returns unexpected token

If your .bashrc does not launch correctly and you see lines like the following:

line19: syntax error near unexpected token 'then'
line 19: ' if[ $? -eq 0 ]; then '

Then, you might have introduced errors when cutting and pasting from a browser. We have seen this error when users use the Chrome browser. Try another such as Firefox.

General SSH troubleshooting

Use this section for general SSH troubleshooting.

ssh -T connection test (GitBash/Mac OSX/Linux)

You can use the ssh -T command to test the Mercurial (hg) or Git (git) connection to Bitbucket. The command below illustrates how to test a Mercurial (hg) connection to Bitbucket:

$ ssh -T hg@bitbucket.org
Permission denied (publickey).

If you don't have any keys loaded in the agent, the response is as illustrated above.

A successful response to a Mercurial connection looks like the following:

$ ssh -T hg@bitbucket.org
conq: logged in as tutorials.

You can use git or hg to connect to bitbucket. Shell access is disabled.

Of course, you can also test the Git connection with the ssh -T  git@bitbucket.org  command structure.

Using ssh verbose mode to track down problems

You can use the -v (verbose) flag with ssh to track down problems with your connection. What happens if you receive a Permission denied (publickey) error but you verified your key is loaded both on your local system and into your Bitbucket account? This happened to me recently.

Running the verbose command:

Output showing the error:

$ ssh -v hg@bitbucket.org
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/manthony/.ssh/config
debug1: Applying options for bitbucket.org
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to bitbucket.org [172.16.10.101] port 22.
debug1: Connection established.
debug1: identity file /Users/manthony/.ssh/manthony type 1
debug1: identity file /Users/manthony/.ssh/manthony-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /Users/manthony/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/manthony/.ssh/manthony
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

In this run, the public key manthony was offered. It failed, the system then tried to use the default key and again failed. If the proper key is offered but fails, check and make sure the key is uploaded to your account. If the key is in the account but it is still failing, try uploading it again. You can also try another key.

If your key isn't offered, make sure the key exists on the local system you are using to connect. Make sure your key is loaded into the key agent. You can do this via a .ssh/config file or manually loading it into the SSH agent with ssh-add. To test if the key is loaded, with ssh-add run the ssh-add -l command. Finally, try recreating the key and uploading it again.

Output showing success:

$ ssh -v hg@bitbucket.org
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/manthony/.ssh/config
debug1: Applying options for bitbucket.org
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to bitbucket.org [172.16.10.101] port 22.
debug1: Connection established.
debug1: identity file /Users/manthony/.ssh/manthony type 1
debug1: identity file /Users/manthony/.ssh/manthony-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /Users/manthony/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by serverhg
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/manthony/.ssh/manthony
debug1: Remote: Forced command: conq manthony
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read PEM private key done: type RSA
Identity added: /Users/manthony/.ssh/manthony (/Users/manthony/.ssh/manthony)
debug1: read PEM private key done: type RSA
Connection closed by 172.16.10.101

Is the ssh-agent running?

On Windows make sure Pageant is running in your system tray:

For GitBash, Mac OSX, or Linux:

Open a terminal window and enter the  ps -e | grep [s]sh-agent command to see if the agent is running:
$ ps -e  | grep [s]sh-agent
 9060 ??         0:00.28 /usr/bin/ssh-agent -l

If the agent isn't running, start it manually with the following command:

$ ssh-agent /bin/bash

Is the identity you want to use loaded?

On Windows, double-click Pageant and check which key is loaded:

On GitBash/Mac OSX/Linux, the the following:

To list the loaded entities:

$ ssh-add -l
2048 4c:80:61:2c:00:3f:9d:dc:08:41:2e:c0:cf:b9:17:69 /Users/manthony/.ssh/workid (RSA)
2048 7a:9c:b2:9c:8e:4e:f4:af:de:70:77:b9:52:fd:44:97 /Users/manthony/.ssh/personalid (RSA)

To load an identity:

$ ssh-add ~/.ssh/identity

With ssh-agent management Bitbucket uses the first key in the list. If you are still having problems, try removing all but the identity you want to connect with, to do this:

$ ssh-add -d ~/.ssh/identity

Using a single key without a config file (Mac OSX and Linux)

Instead of the config file, you can use the ssh-add command to manually load an identity into the ssh-agent management program.

$ ssh-add ~/.ssh/personalid
Enter passphrase for /Users/manthony/.ssh/personalid:
Identity added: /Users/manthony/.ssh/personalid (/Users/manthony/.ssh/personalid)
myhost:~ manthony$


Use the ssh-add command to list the keys that the agent is managing:

$ ssh-add -l
2048 4c:80:61:2c:00:3f:9d:dc:08:41:2e:c0:cf:b9:17:69 /Users/manthony/.ssh/workid (RSA)
2048 7a:9c:b2:9c:8e:4e:f4:af:de:70:77:b9:52:fd:44:97 /Users/manthony/.ssh/personalid (RSA)

In this instance, the Bitbucket server always uses the first key it encounters. So, this is not a good technique to use for multiple identities.

You can remove an identity from the agent using ssh-add with the -d flag. You can also set an identity to expire from the list with the ssh-add command.

ssh-agent on GitBash

If your key is uploaded and you are still having trouble connecting. Make sure you are not running multiple versions of the ssh-agent. To do this, enter the following at the GitBash command line:

$ ps
PID PPID PGID WINPID TTY UID STIME COMMAND
5192 1 5192 5192 ? 500 19:23:34 /bin/ssh-agent
5840 1 5840 5840 con 500 08:38:20 /bin/sh
6116 5840 6116 1336 con 500 08:38:22 /bin/ps

Kill all the agents and restart it. Some users find that the ssh-agent binds to the terminal window they use effectively blocking any further action with SSH. To avoid this problem, run the program as follows:

$ eval 'ssh-agent'

This runs the process and also forks it from the terminal window. 

Operation timed out

You can receive a message similar to the following:

ssh: connect to host bitbucket.org port 22: Operation timed out
fatal: The remote end hung up unexpectedly
Completed with errors, see above

A timeout means that your computer was unable to reach Bitbucket.  This is likely due to something in your own network.  For example, your network administrator may have a firewall rule that blocks the connection.  Talk to your network administrator to resolve the issue. 

Mercurial (or TortoiseHg) on Windows with PuTTygen/Pageant

Use this section if you are working in Microsoft windows with TortoiseHG and managing your keys with PuTTYgen/Pageant.

remote: No supposted authentication methods left to try!

You can get this error, for example, when cloning a repository:

Check the following:

  • Pageant is running and has a key loaded.
  • You have added the corresponding public key into your Bitbucket account.

pushing a new repository is slow or hangs

It could be you have not configured Mercurial compression. On Windows do this:

When sending or retrieving data using SSH, Git does compression for you. Mercurial does not automatically do compression.  If you are using Mercurial, you should enable SSH compression as it can speed up things drastically, in some cases. To enable compression for Mercurial, do the following:
  1. Start the TortoiseHg Workbench.
  2. Select File > Settings.
  3. Make sure you have the global settings tab selected.
  4. Press Edit File.
  5. Add the following line to the UI section:

    ssh = "TortoisePlink.exe" -ssh -2 -batch -C

    When you are done the file should look similar to the following:

    [ui]
    # Name data to appear in commits
    username = Emma Paris <emmap1@atlassian.com>
    ssh = "C:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 -batch -C
  6. Press Save to store your settings and close the file.
  7. Press OK to close the settings dialog.

In Mac OSX or Linux do this:

When sending or retrieving data using SSH, Git does compression for you. Mercurial does not automatically do compression.  You should enable SSH compression as it can speed up things drastically, in some cases. To enable compression for Mercurial, do the following:
  1. Open a terminal window.
  2. Edit the Mercurial global configuration file (~/.hgrc).
  3. Add the following line to the UI section:

    ssh = ssh -C

    When you are done the file should look similar to the following:

    [ui]
    # Name data to appear in commits
    username = Emma <emmap1@atlassian.com>
    ssh = ssh -C
  4. Save and close the file.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport