DD-WRT/Optware SSH and “no matching key exchange method found”

Apologies for yet another non-ESP related post, but this is yet another “note to self” which might possibly be of use to others.  It concerns upgrading OpenSSH, only to find that it is now impossible to log in from the newly upgraded machine to some of your “legacy” servers.

The full story… I have an Asus WL500G (v2) wireless router, which I have never used as an access point.  Instead, it sits quietly in a dark corner of the basement with a 2TB USB disk attached saving selected backups-of-backups from the main server.  It doesn’t matter that it’s slow.  It does matter that it sips electricity and is extremely reliable.  In fact it’s so reliable that I tend to forget all about it and it hasn’t had an upgrade in a few years.  I installed DD-WRT on it when I first got it and then added Optware from “frater” to expand the filesystem and be able to add packages that I needed.  It runs a few other services in addition to its backup functions, but basically just sits there and chunters away quite happily and has never failed.

On the other hand, the main, big-disk back-up system and do-everything server has had hardware and software upgrades many times in the same timeframe, the latest of which was a massive downsizing to an ARM based system.  During the course of that upgrade, the OS was updated and, when trying to copy backups of the configuration files from the Asus machine, I discovered that ssh access no longer worked, with the error on the newly upgraded system being:-

no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

While it was fairly obvious what the problem was (the “new” version of OpenSSH on the upgraded system doesn’t want to use the insecure, older cypher available on the Asus), the fix wasn’t quite so obvious.  Trying to upgrade the OpenSSH version on the Asus came back with a message telling me that I was already on the latest and greatest version (whereas a quick check with “ssh -V” on the Asus itself showed a compile date of “23 Feb 2007”).  Hmmm…

Optware, Optware-2, OOTRW, son-of-optware, second-cousin-twice-removed-of-optware, et-al have all been discontinued and, in the case of Optware2 anyway, the repository is no longer available.  What to do?  Well the obvious answer is to upgrade the whole system (keeping the backup-repository intact) and start from scratch, maybe with Entware-ng, or maybe just the vanilla OS.  At any rate, what I wanted to do was get the backup repository up to date and safely stored away before starting anything at all.

Another quick search on the ‘net gave me an answer to my question from the opposite end (as it were); modify my ssh parameters on the source machine (the ARM system) to tell it to accept the Diffie-Hellman cypher just from the old Asus and nowhere else.  On the command line this can be accomplished with:-

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 beanbrain@asusddwrt.hogbreath.org

The “-o KexAlgorithms=” option tells ssh to add the Diffie-Hellman to the list of acceptable ciphers and this (rather long) command will log me in successfully to the old Asus.  Yay!

What I’d like to do though, is to re-enable the cron jobs on the ARM machine which transfer the updated backup files automatically to the older Asus.  I’m not going to be there at 03:00 in the morning to type in that long command line.  I could update all of the scripts and cron jobs to use that “-o KexAlgo…” option, but that sounds a little too much like hard work and still means I would have to type it in when manually logging in from ARM to Asus and in any other situation where I need to ssh or scp between the machines.  Luckily ssh comes with a raft of configuration files which allow you to set options like this at a system or user level.  Because this is weakening system security to a certain extent, we want to limit this option to a single user (in this case, “beanbrain”) as well as limiting the lame cypher to a single user/machine combination.  To do this we’ll use an entry in the ${HOME}/.ssh/config file for “beanbrain”.

Before we start, use the command ssh -G google.com | egrep kex  to see what ciphers you currently have available.  Note that there will be Diffie-Hellman ciphers in the list, but not a “diffie-hellman-group1-sha1”.  Now, on to that config file.

-Important-  If the .ssh/config file doesn’t already exist for the user, it must be created with secure access permissions.  If the file is readable and/or writeable by everyone, ssh will refuse to start up and throw this error:-

Bad owner or permissions on ${HOME}/.ssh/config

To fix this you need to change the access permission on the config file to be a lot more restrictive.  I would recommend using read/write for the owner of the file and no-one else.  For our user “beanbrain”, this can be achieved using the command:-

chmod 0600 ~beanbrain/.ssh/config

You should list the new permissions with ls -al following this change and ensure that not only the permissions are correct, but also that the config file is actually owned by the user (and not “root”).

Okay, now that we’ve created the file, lets add the magic line to get things working.  This is the example given in the OpenSSH legacy page:-

Host somehost.example.org
     KexAlgorithms +diffie-hellman-group1-sha1

There are two things to note here.  First, the KexAlgorithms line must start with a TAB  character to delimit it from the “Host” specifiers.  Secondly, the example shows a fully-qualified hostname, but generally on a local network we will be using a simple hostname (when using ssh interactively on the command-line) , but probably fully-qualified in any scripts or cron jobs, too.  Luckily the “Host” line accepts multiple names, separated by a single space, so we can change the example to a real-world entry for our Asus:-

Host  asusddwrt.hogbreath.org  asusddwrt
     KexAlgorithms +diffie-hellman-group1-sha1

Now both our fully-qualified and simple hostnames will both work.

After this change has been completed, our ssh -G google.com | egrep kex command will display the “diffie-hellman-group1-sha1” as the last entry in the cipher list and we’re good to go with both interactive, command-line access and from scripts.

Now that we have the cron jobs working and the backup data copying across, it’s time for me to gird my loins and get stuck into that upgrade.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s