SSH key exchange algorithm negotiation payload growth

[Damien Miller]

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