When you’re troubleshooting connectivity issues between Secure Shell (SSH)/Secure File Transfer Protocol (SFTP) clients and servers, it pays to inspect the error messages generated on both sides of a connection. Those messages often provide vital clues about the problem. If your error messages involve the Diffie-Hellman-Group1-SHA1 key exchange algorithm, you’ll want to stick around. In the succeeding sections, we’ll be discussing the underlying cause of this particular issue and how to fix it.

First, let’s briefly overview SSH/SFTP key exchange algorithms.

What are SSH key exchange algorithms?

An SFTP or SSH key exchange algorithm is a specific method that an SFTP/SSH client and an SFTP/SSH server employ to exchange temporary key exchange data that are digitally signed for authenticity by the server’s host key. The purpose of a key exchange is to generate a shared secret and an exchange hash.

Since these cryptographic artifacts are in turn used in encryption and authentication operations, they play an important role in securing your SFTP/SSH connection. As such, you must ensure the key exchange process is secure.

There are multiple ways or methods of exchanging keys. In cryptographic parlance, these different methods are called key exchange (KEX) algorithms. Some of the most commonly used Diffie-Hellman group exchange algorithms include:

As cryptographic algorithms — including KEX algorithms — get older, cryptanalysts become more familiar with their inner workings. Sometimes, these cryptanalysts discover vulnerabilities in these algorithms.

In the case of diffie-hellman-group1-sha1, this KEX algorithm is known to suffer from weak key sizes. Generally, higher group numbers correspond to stronger keys. DH group 1 only uses 768-bit, which is now considered breakable. Not only that, diffie-hellman-group1-sha1 is also incapable of supporting forward secrecy and susceptible to precomputation attacks, thereby making it a security risk.

Identifying the root cause of the issue

The presence of these vulnerabilities has prompted many SFTP/SSH client and server vendors to disable diffie-hellman-group1-sha1 on their software or stop supporting it altogether. However, some SFTP/SSH servers that have already been deployed in production environments still use this KEX algorithm.

This problem isn’t confined to SSH software applications. Legacy network devices that support SSH suffer from this issue as well. For instance, I’ve seen similar issues when IT admins attempt to establish SSH sessions with old Cisco firewalls, switches and routers.

Basically, when a client that no longer uses diffie-hellman-group1-sha1 attempts to connect to a server that still does, the two parties will fail to negotiate a suitable KEX algorithm. As a result, they won’t be able to establish a connection. In most cases, you can tell if a KEX algorithm incompatibility is causing a connectivity issue by inspecting the SFTP client-generated errors.

For example, FileZilla generates an error message that goes like this:

Error: The first key exchange algorithm supported by the server is diffie-hellman-group1-sha1, which is no longer secure. Aborting connection.

Error: Could not connect to the server

Other SFTP/SSH clients should see similarly worded error messages, so the issue can be easy to spot.

How to fix the problem — 4 solutions

So how do you fix a connectivity issue that involves the diffie-hellman-group1-sha1 key exchange algorithm? Here are four options.

Band-aid solution #1: Use outdated SFTP clients (NOT RECOMMENDED)

While recent versions of SSH/SFTP clients no longer support diffie-hellman-group1-sha1, legacy versions do. So, one workaround to this issue is to simply use older versions of your SSH or SFTP client. Just remember that diffie-hellman-group1-sha1 is plagued with vulnerabilities. So, any SSH/SFTP client that uses it is no longer secure.

Now, if you don’t have access to legacy versions of your SSH/SFTP client, you can try the second option below.

Band-aid solution #2: Specify your preferred KEX algorithm

If your client allows it, you can manually specify diffie-hellman-group1-sha1 as the preferred KEX algorithm. For example, if you’re using the ssh command-line client, you may connect to your ssh server using the following command:

ssh -o KexAlgorithms=diffie-hellman-group1-sha1 user@hostname

This forces the command-line SSH client to recommend diffie-hellman-group1-sha1 to the server. Note that you may replace the hostname with an IP address.

You can even add your preferred ciphers like so:

ssh -o KexAlgorithms=diffie-hellman-group1-sha1 -c 3des-cbc,aes128-cbc,aes256-cbc user@hostname

ssh -o KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-ctr,aes192-ctr,aes256-ctr username@hostname

Alternatively, you may try modifying your SSH client’s ssh_config file so that you don’t have to specify diffie-hellman-group1-sha1 every time you connect. Follow these steps to do that:

Please note that specifying diffie-hellman-group1-sha1 as your preferred KEX algorithm may not work if your version of OpenSSH has already phased out the algorithm in question.

Again, bear in mind that, by circumventing your SSH/SFTP client’s omission of diffie-hellman-group1-sha1 as a supported KEX algorithm, you’re exposing your SSH/SFTP connections to cyber threats.

Ultra-restrictive solution: Use only the strongest DH group

Unlike the two solutions we discussed earlier, this solution is meant to be applied on the server side. It’s based on the following premise. Since key exchange algorithms need to be secure, why not just use the strongest DH group on your server? In the list above, for example, that would be diffie-hellman-group17-sha512. While this option can certainly provide the most secure SFTP/SSH connections, it’s also very restrictive.

Not all SFTP/SSH clients are capable of supporting the strongest DH group. All users that attempt to connect to your server through either a legacy client or a client that doesn’t support diffie-hellman-group17-sha512 will be unable to connect. Indeed, in a practical sense, the most secure option isn’t always the best one.

Best solution: Disable insecure key exchange methods

The best option is to disable insecure key exchange algorithms and leave the rest as is, regardless of their cryptographic strengths. This option minimizes security risks while maintaining a high level of interoperability. In our case, the insecure KEX algorithm in question is diffie-hellman-group1-sha1, so we have to disable that.

On Ubuntu, RedHat, Fedora and other Linux distributions

All major Linux distros use OpenSSH as their SSH/SFTP application. So, unless you’re using some obscure Linux distribution, the following steps should work.

On JSCAPE MFT Server

If you’re using JSCAPE MFT by Redwood , the process of disabling diffie-hellman-group1-sha1 is much easier. You may disable this KEX algorithm by navigating to Domains > View Domains > [the domain running SFTP] > Services > Listeners > SFTP/SCP tab > Algorithms > Key Exchanges tab. From there, you may un-tick the diffie-hellman-group1-sha1 checkbox to disable that KEX algorithm. Click OK to apply the changes.

Want to try this out in your environment? ↓
Notice that you can also make changes to your SFTP server’s host/public keys, ciphers, MACs (e.g. hmac-sha1, hmac-sha2-512, hmac-sha2-512-96, etc) from the same window.

Get maximum interoperability with JSCAPE MFT Server

JSCAPE MFT gives you extensive flexibility in choosing SFTP algorithms , which in turn enables you to achieve maximum interoperability. This means you can support a wider range of clients without compromising security. Not only that, JSCAPE MFT also enables you to offer other file transfer services aside from SFTP. This includes File Transfer Protocol Secure (FTPS), Applicability Statement 2 (AS2), Odette File Transfer Protocol (OFTP) and many others.

By expanding protocol support beyond SFTP, you can accommodate even more users and trading partners. Would you like to see JSCAPE MFT in action? Schedule a quick demo now .