SSH key exchange algorithm negotiation payload growth

[Kent R. Spillner]

Howdy-

TL;DR

An SSH daemon for a memory-constrained embedded platform didn't work with a recent OpenSSH client because it couldn't handle the payload size during key exchange.  In general, what should SSH implementors in such limited environments do to ensure forwards compatibility with future OpenSSH releases?


I am unable to SSH to any of my HP servers' iLO2 interfaces using OpenSSH 6.2p1.  My particular problem looked similar to earlier compatibility problems between OpenSSH and mpSSH, the iLO2 SSH daemon, e.g. http://marc.info/?l=openssh-unix-dev&m=130574789103948&w=2, but unfortunately the suggested work-arounds didn't work in my case.

I reported the issue to HP (http://h30499.www3.hp.com/t5/ITRC-Remote-Lights-Out-Mgmt-iLO/Unable-to-SSH-to-iLO2-with-OpenSSH-6-2/td-p/6050925) and it appears they fixed the problem for a future release of iLO2: http://h30499.www3.hp.com/t5/ITRC-Remote-Lights-Out-Mgmt-iLO/Unable-to-SSH-to-iLO2-with-OpenSSH-6-2/m-p/6055771#M7322

I'm curious, though, how other embedded SSH implementors maintain forwards compatibility with future releases of OpenSSH.  Am I correct in reading RFC 4253 sections 6.2 - 6.5 and section 7.1 as saying that implementations must be prepared to accept an arbitrary number of algorithms of each type during initial key exchange?

When I was troubleshooting this issue I tried playing around with different combinations of -o KexAlgorithms and -o HostKeyAlgorithms at the command line.  Are there other configuration paramters for the other name-lists during algorithm negotiation, e.g. encryption_algorithms_client_to_server, compression_algorithms_server_to_client, etc?

Thanks in advance!

Best,
Kent