Comment 20 for bug 556132

Somehow I didn't read this when I marked the bug fix released.

On Wed, 12 Jan 2011 03:47:11 -0000, Martin Pool <email address hidden> wrote:
> Tim pointed out that the ssh server has not yet been upgraded to the
> revision that fixes this.

I'm now confused by timezones, but when did he say this? The SSH server
was upgraded to a revision that tried to fix this bug by the 11.01
update that happened during the rally.

> I think I got a false pass because OpenSSH defaults to never initiating
> rekeying from the client.

Er. This is not true, according to my understanding of things.

man ssh_config ->

     RekeyLimit
             Specifies the maximum amount of data that may be transmitted
             before the session key is renegotiated. The argument is the num‐
             ber of bytes, with an optional suffix of ‘K’, ‘M’, or ‘G’ to
             indicate Kilobytes, Megabytes, or Gigabytes, respectively. The
             default is between ‘1G’ and ‘4G’, depending on the cipher. This
             option applies to protocol version 2 only.

I'm not sure whether openssh's sshd ever initiates rekeys (I think it
may do so based on time rather than data, according to some mailing list
posts I found?) but Launchpad's conch-based one certainly does not.

> If I set 'RekeyLimit 50k' then it does hang, and presumably will
> eventually time out. On the other hand running the same command
> against qastaging, which does have this fix, succeeds.

Note that rekeying involves many round trips and so frequent rekeying
over a high latency link (such as over wifi at the rally) will be very
slow. How did you determine it had hung?

> So this should be fixed on the next major/with-downtime rollout of
> Launchpad, in a couple of weeks(?).

Did you write this before or after the 11.01 rollout?

Cheers,
mwh