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.) Curiously, diffie-hellman-group1-sha1, which is the only one supported by the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2); I was hoping that I could use it to explicitly request smaller DH but ultimately it still dies with "Invalid key length" error. Is this an oversight or is there a particular logic to intentionally breaking compatibility with a not-insignificant base of installed equipment? Thank you, Jacob Leifman Educational Technology Weymouth Public Schools -- CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is intended only for the individual or entity to which it is addressed and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient but do not wish to receive communication through this medium, please advise the sender immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Weymouth Public Schools. www.weymouthschools.org/
