Bitbucket Server throws 'No kex alg' error while performing git operations from RHEL5 machines.

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center 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

Summary

Users may face a "no kex alg" error while performing git clone from RHEL/CentOS 5. 

Environment

7.17.0

Client : RHEL/CentOS 5

Diagnosis

git clone output
git clone ssh://git@host.docker.internal:8004/test/tda.git
Cloning into 'tda'...
no kex alg
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
fatal: Could not read from remote repository.

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

Cause

Currently, Bitbucket bundle with Apache SSHD 2.8+ which no longer supports SHA1-based key exchanges by default. However, there are some systems that still use these SHA1 algorithms like in this case.

Solution

The solution is to upgrade the Bitbucket to one of the latest versions or upgrade the RHEL5 to a higher release like RHEL6 +.

A new boolean property plugin.ssh.dhgex.allow-sha1 was implemented for the fixed versions (Bitbucket 7.20.0, 7.19.3, 7.17.5) . Setting this property to true allows the usage of the following DH SHA1 key exchange algorithms.

  • diffie-hellman-group1-sha1
  • diffie-hellman-group14-sha1
  • diffie-hellman-group-exchange-sha1

The default value currently set to true in above versions so no need to explicitly set the value in the bitbucket.properties file. However, this default value will be changed to false in the Bitbucket version 8.0 major release but will still be configurable by Bitbucket Server admins. Furthermore, this property may be removed in future 8.x releases if the version of Apache SSHD used by then also fully removes these insecure algorithms.

Last modified on Aug 9, 2022

Was this helpful?

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