openssh unix dev - May 2013 - SSH key exchange algorithm negotiation payload growth

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

Kent R. Spillner wrote:
> I'm curious, though, how other embedded SSH implementors maintain
> forwards compatibility
More clever parsing of incoming packets, I guess?

> 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?
See Ciphers and Compression in man ssh_config and man sshd_config.


//Peter

On Tue, 7 May 2013, Kent R. Spillner wrote:
> 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?
Not assume fixed size buffers will always fit proposal strings :)

The maximum likely size of a KEXINIT packet is always going to be smaller
than the 32KB minimum payload length required by RFC4253. 
> 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?
Up to the 32KB packet size required in section 6.1.
> 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?
The options that select the contents of the KEXINIT packet are:

Ciphers
MACs
Compression
HostKeyAlgorithms
KexAlgorithms

If you ever encounter a broken implementation that chokes on something
in the KEXINIT packet, you can use one (or all) of these to remove the
offending morsel.

-d