Bitbucket Server throws 'No kex alg' error while performing git operations from RHEL5 machines.
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
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
1
2
3
4
5
6
7
8
9
10
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.
Was this helpful?