mjurgens
DD-WRT Novice
Joined: 12 Jan 2011
Posts: 40
|
 Posted: Fri Jul 24, 2020 6:55 Post subject: Workaround: SSH Keyexchange is slow (long delays connecting) |
 |
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 -
| Code: | | 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:
| Code: | | 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:
| Code: | # allow older algorithms for specific hosts, you can use * for wildcarding where HOSTNAME1 etc must be substituted for your real hostnames or IP Addresess
Host HOSTNAME1 HOSTNAME2 HOST*IPADDRESS
# 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).
| Code: |
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 |
|
|
elatllat
DD-WRT Novice
Joined: 20 Feb 2020
Posts: 31
|
| Posted: Fri Jul 24, 2020 12:19 Post subject: |
|
| Code: | 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,kexguess2@matt.ucc.asn.au
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
slow
real 0m6.503s
user 0m0.013s
sys 0m0.000s
|
|
|
egc
DD-WRT Guru
Joined: 18 Mar 2014
Posts: 12882
Location: Netherlands
|
|
