Workaround: SSH Keyexchange is slow (long delays connecting)

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> General Questions
Author Message
DD-WRT Novice

Joined: 12 Jan 2011
Posts: 25

PostPosted: Fri Jul 24, 2020 6:55    Post subject: Workaround: SSH Keyexchange is slow (long delays connecting) Reply with quote
I'm writing this post as an information piece that might help some other people who are experiencing or might experience slow SSH connections in the future. I would have added it to one of the existing posts on this topic except that they are locked.

The ultra short summary is:

Old hardware is not the problem, its poor software. So you can partially address this by using a (Linux) command like this to force an older key exchange algorithm for "good enough" security if your risk tolerance allows it -
ssh -o KexAlgorithms=diffie-hellman-group1-sha1 HOSTNAME

A longer summary is as follows:

• Later firmware versions typically implement later versions of security algorithms
• Old hardware is not always to blame
• Sometimes the software is poorly written and results in significantly more processor power being required than it might otherwise and this results in slow SSH connections
• If your risk tolerance allows you to accept a reduce security posture then using an older version of a security algorithm can typically reduce the processing requirements and make the connections faster.

The last bullet point is the fix offered by this post and should allow those not wanting to spend any money on hardware, improve their SSH connection times while still maintain security that is “good enough”.

For many people, for home networks, you don’t really need any encryption for your network. You’re unlikely to get an attacker sniffing your network looking for valuable information (it’s unlikely to be worth their time and there are easier methods). They are more likely just to breach your network using vulnerabilities/phising etc and takeover equipment that way. Because of this it is often totally acceptable to force SSH to use older algorithms that use less processing power. This can bring the SSH connection times back down to a more acceptable level.

In order to do this using SSH on Linux you run a command like:
ssh -o KexAlgorithms=diffie-hellman-group1-sha1 HOSTNAME

this forces the use of an older but still encrypted algorithm. Its probably annoying to do this each time you run ssh, so we can change the configuration on the ssh client to do this for us each time. When we do this, we only want to target specific hosts for reduced security. In the ssh_config file (often /etc/ssh/ssh_config) you can add the following 4 lines:

# allow older algorithms for specific hosts, you can use * for wildcarding where HOSTNAME1 etc must be substituted for your real hostnames or IP Addresess
   # lock in the following Keyexchange algorithm
   KexAlgorithms diffie-hellman-group1-sha1

I have found that this at least halves the SSH connection time, while still maintaining “good enough” security.

More Details below (but most people can stop here):

For the purposes of this post, long or slow is defined as taking more than 1 second. Sometimes it can be significantly longer than that.

You might be tempted to blame old hardware but this is not always the case, and in fact what I have found is that the software plays a significant role in the slowness. This actually leads to some good news, in that, since it is software you can actually change the configuration and impact the connection speed for the better.

The fundamental issue is that as time goes on, in order to maintain the same security level, we need to make the crypto-algorithms harder to break. This typically means things like, increasing key sizes, using more modern algorithms and restricting old, insecure algorithms. As we try to maintain security, this typically requires more processing power (hence why people automatically point to upgrading hardware), however, there can be poor implementations of algorithms or other factors which can mean inordinate amounts of additional processing are required to process the same things. It is the last thing that I am addressing with this post.

While you can often hide poor software performance with faster hardware, sometimes you can't and you just have to make the software better.

Anyway, let's get too it.

The context of this is that in my house I have 5 access points to get the coverage that I need. Brick walls, concrete and steel make it impossible to get good coverage everywhere with a single access point. I’ve been running Linksys E2000s and WRT320Ns for a while now and they work well, often still faster than my Internet connection can perform and hence for many uses they do not need upgrading for Wifi speed improvements. Plus, there is 5 of them and if I wanted to upgrade them all then that’s 5 times the cost of a single AP installation. If you suggest to me that I should just upgrade my hardware then you are not fully applying your cursory logic to my situation.

Over the years, I have upgraded DDWRT on these APs occasionally. For a long time now, they have been very stable on firmware version 16785. On this firmware version SSH connection times are sub-second and so, perfectly acceptable.

A few years back I thought I’d upgrade to a more recent version. I landed on v28647 which was relatively recent at the time. It worked well except for one thing, the SSH connection time was terrible, in the order of 6-8 seconds. I didn’t pursue that or any other version at the time and left them for a few more years as-is.

Then recently I thought I’d have another go. I landed on v37305. This worked well except SSH connection times were still slow, but not as slow as on v28647. I spent a bit of time trying to understand why it was so slow and found that it was all due to the key exchange algorithm. Once you were connected, it worked perfectly fine. I then downgraded the key exchange algorithm and found that I could easily halve the time the connections took to establish.

I did some further testing and found that it was not a hardware problem as some might casually think but it was purely a software problem. Upgrading the hardware to a faster processor would simply mask the problem.

On the same hardware, using the exact same key exchange algorithms and by varying the firmware version alone, I found that I could get SSH connections times of 0.7s through to 6.7s. It is the version of the dropbear software used by DDWRT as the SSH server that drives the most change.

Whilst the default key exchange algorithm for each firmware version is generally more secure as time goes on, forcing the key exchange algorithm back to an older version is most likely totally acceptable for many people in many situations.

I found that varying the cipher made no perceptible difference to the connection time.

If you are reading this post many years after it was written and you have slow SSH connection times you probably are also the victim of poor software and you probably will find that varying the algorithm will help you.

This post advocates using a reduced security posture only when your risk tolerance allows for it. For home networks, I’d suggest that this applies to most people, most of the time.

Here’s the data from my testing (sorry a little bit hard to make this table look right).

Model   Firmware   Cipher   MAC   KEX   SSH Connection Time (sec)
WRT320N   28647 mini K2.6   Aes-256-ctr   Hmac-sha1   diffie-hellman-group14-sha1   6.708
WRT320N   28647 mini K2.6   Aes-128-ctr   Hmac-sha1   diffie-hellman-group1-sha1   3.054
WRT320N   37305 mini K2.6   Aes-256-ctr   Hmac-sha1   diffie-hellman-group14-sha256   4.469
WRT320N   37305 mini K2.6   Aes-128-ctr   Hmac-sha1   diffie-hellman-group1-sha1   2.094
E2000   16785 big K2.6   Aes-256-ctr   Hmac-sha1   diffie-hellman-group1-sha1   0.704
E2000   16785 big K2.6   Aes-128-ctr   Hmac-sha1   diffie-hellman-group1-sha1   0.699
E2000   37305 mini K2.6   Aes-256-ctr   Hmac-sha1   diffie-hellman-group14-sha256   4.748
E2000   37305 mini K2.6   Aes-128-ctr   Hmac-sha1   diffie-hellman-group1-sha1   2.126
EA6700   28647 std K3.0   Aes-256-ctr   Hmac-sha1   diffie-hellman-group14-sha1   0.600
EA6700   28647 std K3.0   Aes-128-ctr   Hmac-sha1   diffie-hellman-group1-sha1   0.313
DD-WRT Novice

Joined: 20 Feb 2020
Posts: 12

PostPosted: Fri Jul 24, 2020 12:19    Post subject: Reply with quote
ssh -o KexAlgorithms=diffie-hellman-group1-sha1 $A echo ok
Unable to negotiate with $A: no matching key exchange method found. Their offer: diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,

time ssh -o KexAlgorithms=diffie-hellman-group14-sha1 $A echo slow
DD-WRT v3.0-r43334 giga (c) 2020 NewMedia-NET GmbH
Release: 06/04/20
Board: Asus RT-AC66U

real   0m6.503s
user   0m0.013s
sys   0m0.000s

Joined: 18 Mar 2014
Posts: 6633
Location: Netherlands

PostPosted: Fri Jul 24, 2020 12:31    Post subject: Reply with quote

extensively discussed

Security has its price Smile

Routers:Netgear R7800, R6400v1, R6400v2, Linksys EA8500, EA6900 (XvortexCFE), E2000 (converted WRT320N), WRT54GS v1.
OpenVPN Policy Based Routing:
Install guide R6400v2:
OpenVPN Server Setup:
Install guide R7800:
Wireguard Server setup guide:
Wireguard Client setup guide:
Wireguard Advanced setup guide:
Forum Guide Lines (important read):
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> General Questions All times are GMT


Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum