Troubleshooting SSH issues

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform Notice: Cloud, Server, and Data Center - This article applies equally to all platforms.

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

  

If you're having problems with SSH, here are some things you can try when troubleshooting your issues. There are two classification types of issues you can have, loading the ssh key into Bitbucket and connecting to Bitbucket.  This article should help you with both by linking to more detailed information on the error you have.  You should also remember that this is attempting to be, but is not an exhaustive list of issues you can have.  There may be another more direct Knowledge Base Article that matches your issue not linked here. This Knowledge Base Article is also not intended to be a definitive explanation of the ssh logs.  We are only intending to point out common issues our users have seen.  Places in the logs where we do not see any issues the explaination is probably over simplified.  

If you're using Sourcetree, some of these solutions come with Sourcetree steps. However, you may need to using the command line for others. From a repository in Sourcetree, you can find the command line by clicking Terminal in the top right.

If your issue is not linked here, keep the output of the debug logging you see.  Community or Support will need it to provide you more data and will want to document the failure.

Loading keys into bitbucket.org

These are issues when adding ssh public keys into Bitbucket. 

Invalid SSH Key

When adding an SSH public key to Bitbucket Cloud, the following error appears: Invalid SSH Key or Invalid SSH Key (ssh-keygen).  Please see Invalid SSH key for more details.

Someone has already registered that SSH key

Please see Someone has already registered that SSH key if you see the following error when attempting to add a new SSH key in Bitbucket Cloud:

Someone has already registered that SSH key.

Bitbucket Cloud SSH host key rotation - FAQ

When connecting to bitbucket.org via SSH, if you see the below error, please refer to Bitbucket Cloud SSH host key rotation - FAQ

Offending RSA key in /Users/macmagician/.ssh/known_hosts:1
Host key for bitbucket.org has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

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


Errors connecting to Bitbucket.

If you are connecting to Bitbucket using ssh, you could see some of these issues.  What is listed here is the debug logging analysis you can use to point to a particular issue.

This is the command we will be using to get debug data from your client.  The -v is one level of verbose logging.  The -T is to avoid an interactive shell.  This command can output lots of data.  

ssh -vvv -t bitbucket.org 

You can also turn on ssh debug logging while using git.  

GIT_SSH_COMMAND="ssh -vvv" git <command> 

From here, we will take sections of the ssh debug output and explain what it means.   For instance, the first section has the command being run and one line of debug logging.  each section will be a different length. 

Full unedited debug text

This is the full unedited debug text:

Click here to expand...

$ ssh -v -t bitbucket.org
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/dlaser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to bitbucket.org port 22.
debug1: Connection established.
debug1: identity file /Users/dlaser/.ssh/id_rsa type -1
debug1: identity file /Users/dlaser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/dlaser/.ssh/id_dsa type -1
debug1: identity file /Users/dlaser/.ssh/id_dsa-cert type -1
debug1: identity file /Users/dlaser/.ssh/id_ecdsa type -1
debug1: identity file /Users/dlaser/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/dlaser/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/dlaser/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/dlaser/.ssh/id_ed25519 type 3
debug1: identity file /Users/dlaser/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/dlaser/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/dlaser/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/dlaser/.ssh/id_xmss type -1
debug1: identity file /Users/dlaser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version conker_74f550b922 f6f746d1987b
debug1: compat_banner: no match: conker_74f550b922 f6f746d1987b
debug1: Authenticating to bitbucket.org:22 as 'dlaser'
debug1: load_hostkeys: fopen /Users/dlaser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E
debug1: load_hostkeys: fopen /Users/dlaser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /Users/dlaser/.ssh/known_hosts:288
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/dlaser/.ssh/id_rsa
debug1: Will attempt key: /Users/dlaser/.ssh/id_dsa
debug1: Will attempt key: /Users/dlaser/.ssh/id_ecdsa
debug1: Will attempt key: /Users/dlaser/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/dlaser/.ssh/id_ed25519 ED25519 SHA256:1ULdLheARnciJmwL80PAJ2Ao3dvfiTMS5E2vyEHcvGE
debug1: Will attempt key: /Users/dlaser/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/dlaser/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss-cert-v01@openssh.com,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-rsa-cert-v01@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/dlaser/.ssh/id_rsa
debug1: Trying private key: /Users/dlaser/.ssh/id_dsa
debug1: Trying private key: /Users/dlaser/.ssh/id_ecdsa
debug1: Trying private key: /Users/dlaser/.ssh/id_ecdsa_sk
debug1: Offering public key: /Users/dlaser/.ssh/id_ed25519 ED25519 SHA256:1ULdLheARnciJmwL80PAJ2Ao3dvfiTMS5E2vyEHcvGE
debug1: Server accepts key: /Users/dlaser/.ssh/id_ed25519 ED25519 SHA256:1ULdLheARnciJmwL80PAJ2Ao3dvfiTMS5E2vyEHcvGE
debug1: Authentication succeeded (publickey).
Authenticated to bitbucket.org ([18.205.93.1]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: channel 0: setting env LC_TERMINAL_VERSION = "3.5.0beta7"
debug1: channel 0: setting env LC_TERMINAL = "iTerm2"
PTY allocation request failed on channel 0


Analyze Debug

This section has the ssh client debug lines with the analysis that follows. Known issues with Knowledge Base Articles will be linked. For more info on these logs, you might look at Secure Shell (SSH) Protocol Parameters.

$ ssh -v -T bitbucket.org 
OpenSSH_8.6p1, LibreSSL 3.3.6debug1: Reading configuration data /Users/user/.ssh/config

Start of ssh config.  These logs show you the versions of the SSH client being used on your local system. 

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling

This section tells what files were used to configure your local ssh client.  This can change based on the user who is making the connection.

debug1: Connecting to 192.168.1.4 [192.168.1.4] port 22.
debug1: Connection established.

 If you see "Connection established" this means the tcp connection to bitbucket.org is working.  This is an example of a successful connection.  Expand to see errors:

Click here to expand...
ssh: connect to host bitbucket.org port 22: Connection timed out
ssh: connect to host bitbucket.org port 22: Operation timed out
fatal: The remote end hung up unexpectedly
Completed with errors, see above
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: identity file /Users/user/.ssh/id_ecdsa type -1
debug1: identity file /Users/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/user/.ssh/id_ed25519 type 3
debug1: identity file /Users/user/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/user/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/user/.ssh/id_xmss type -1
debug1: identity file /Users/user/.ssh/id_xmss-cert type -1

A -1 means an error.  So either the file was not a ssh key or the file did not exit.  I this case, the identity choses was /Users/user/.ssh/id_ed25519 because it had the maximum value, 3.

debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version conker_a0c557575e c5189741741a
debug1: compat_banner: no match: conker_a0c557575e c5189741741a

This section is part of SSH protocol negotiations.

debug1: Authenticating to bitbucket.org:22 as 'user'
debug1: load_hostkeys: fopen /Users/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory

This section shows data on the ssh_known_hosts files that are attempting to be read.  Most of the time this can be ignored.  

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received

This section is more parts of SSH protocol negotiations.  This section explains the type of encryption ssh will use for the session.

debug1: Server host key: ssh-rsa SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E
debug1: load_hostkeys: fopen /Users/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:3

These log messages show bitbucket.org Server key and where it matched in the known_hosts file.  In this case the known_hosts file, /Users/user/.ssh/known_hosts, matched the server key on line 3.

Click here to expand...

If you have not connected to bitbucket.org before, or bitbucket.org was removed from the known_hosts file, please see this article for more details: The authenticity of host 'bitbucket.org (104.192.143.1)' can't be established.

The authenticity of host 'bitbucket.org (2406:da00:ff00::22cd:e0db)' can't be established.
RSA key fingerprint is SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E.
Are you sure you want to continue connecting (yes/no)?
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks

This section is more parts of SSH protocol negotiations. This is how ssh gets symmetric keys between client and server. 

debug1: Will attempt key: /Users/user/.ssh/id_rsa
debug1: Will attempt key: /Users/user/.ssh/id_dsa
debug1: Will attempt key: /Users/user/.ssh/id_ecdsa
debug1: Will attempt key: /Users/user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/user/.ssh/id_ed25519 ED25519 SHA256:1ULdLheARnciJmwL80PAJ2Ao3dvfiTMS5E2vyEHcvGE
debug1: Will attempt key: /Users/user/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/user/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-nistp521,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ssh-dss,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/id_rsa
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug1: Trying private key: /Users/user/.ssh/id_ecdsa
debug1: Trying private key: /Users/user/.ssh/id_ecdsa_sk
debug1: Offering public key: /Users/user/.ssh/id_ed25519 ED25519 SHA256:1ULdLheARnciJmwL80PAJ2Ao3dvfiTMS5E2vyEHcvGE
debug1: Server accepts key: /Users/user/.ssh/id_ed25519 ED25519 SHA256:1ULdLheARnciJmwL80PAJ2Ao3dvfiTMS5E2vyEHcvGE
debug1: Authentication succeeded (publickey).
Authenticated to bitbucket.org ([18.205.93.1]:22)

This section is how the ssh clients identifies the user.  In this case, Bitbucket Cloud is allowing the client to attempt to identify using the ssh public key.  The ssh client offered the id in /Users/user/.ssh/id_ed25519 to Bitbucket.  If Bitbucket does not accept the key, you will not see Authentication succeeded, you should see an error like: No more authentication methods to try.  

Click here to expand...

If Bitbucket is not accepting your key, you can get an error like this.

debug1: Trying private key: .ssh/aws/user.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
user@bitbucket.org: Permission denied (publickey).

See this link for more details: remote: No supported authentication methods left to try!


debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: channel 0: setting env LC_TERMINAL_VERSION = "3.5.0beta7"
debug1: channel 0: setting env LC_TERMINAL = "iTerm2"
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
authenticated via ssh key.

You can use git to connect to Bitbucket. Shell access is disabled
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2284, received 1916 bytes, in 0.1 seconds
Bytes per second: sent 22602.4, received 18960.7
debug1: Exit status 0
$

This section is ssh setting up the terminal environment and setting up shell access. In this case, Bitbucket Cloud has interactive shells disabled.  Only non interactive shells are allowed.  For security reasons, the only actions over ssh that are allowed are the ones that git requires.  So ssh exits the session while providing some data on the connection.

Click here to expand...

On possible problem is if you have multiple SSH keys configured to access different Bitbucket accounts, you may encounter the below error while performing Git operations like clone, push, etc.

The requested repository either does not exist or you do not have access. If you believe this repository exists and you have access, make sure you're authenticated.
fatal: Could not read from remote repository.

See this link for more details about how to confirm ssh is using the right key: Multiple SSH Keys settings for different Bitbucket Cloud Accounts


But it also provided non debug data about how the user was authenticated. This was a successful ssh session.



Here is a list of the references above.


Last modified on Dec 4, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.