>I was finally able to bring our OpenBSD based Network Management System up >to the current OS release (it was a couple of years out of date) but this >process broke access to a large number of older HP switches on our network. >Thorough analysis of the problem and study of the source code lead me to >believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14: > >increase the minimum modulus that we will send or accept in >diffie-hellman-group-exchange to 2048 bits; > >Within the file it further explains that this is mitigation for DH >precomputation attacks. I understand and appreciate strengthening server >code. But this breaks the use of SSH client leaving little recourse other >than perhaps telnet with NO encryption instead of somewhat weak encryption, >as the "server" is outside of our control. (I already checked that we have >the latest firmware, less than one year old.)
If your switch management is located on a locked-down intranet, aka 'darknet', you can handle this with configuration, or not update the clients that connect to their legacy servers. But I guess they are not on a darknet, because you worry about telnet. >Is this an oversight or is there a particular logic to intentionally >breaking compatibility with a not-insignificant base of installed equipment? Absolutely the latter. It is intentional. Security and interopability often collide, especially as new research papers get written and computational abilities expand. Circumstances arise where both needs cannot be satisfied and past decisions must be evaluated and upgraded. Decisions like this are not taken lightheartedly. BTW you can contact HP tech support and tell them that the latest Cisco Nexus productline just performed a update to latest (well 6 months ago) OpenSSH. Including ditching SSH1 support. Cisco has shorter lifecycles than HP, but did so even for many EOL products in that line. So HP could get around to this.
