PuTTY will not rekey due to elapsed time. The SSH-2 protocol
specification recommends a timeout of at most 60 minutes.
+You might have a need to disable time-based rekeys completely for the same
+reasons that keepalives aren't always helpful. If you anticipate
+suffering a network dropout of several hours in the middle of an SSH
+connection, but were not actually planning to send \e{data} down
+that connection during those hours, then an attempted rekey in the
+middle of the dropout will probably cause the connection to be
+abandoned, whereas if rekeys are disabled then the connection should
+in principle survive (in the absence of interfering firewalls). See
+\k{config-keepalive} for more discussion of these issues; for these
+purposes, rekeys have much the same properties as keepalives.
+(Except that rekeys have cryptographic value in themselves, so you
+should bear that in mind when deciding whether to turn them off.)
+Note, however, the the SSH \e{server} can still initiate rekeys.
+
\b \q{Max data before rekey} specifies the amount of data (in bytes)
that is permitted to flow in either direction before a rekey is
initiated. If this is set to zero, PuTTY will not rekey due to
}
-PuTTY can be prevented from initiating a rekey entirely by setting
-both of these values to zero. (Note, however, that the SSH
-\e{server} may still initiate rekeys.)
-
-You might have a need to disable rekeys completely for the same
-reasons that keepalives aren't always helpful. If you anticipate
-suffering a network dropout of several hours in the middle of an SSH
-connection, but were not actually planning to send \e{data} down
-that connection during those hours, then an attempted rekey in the
-middle of the dropout will probably cause the connection to be
-abandoned, whereas if rekeys are disabled then the connection should
-in principle survive (in the absence of interfering firewalls). See
-\k{config-keepalive} for more discussion of these issues; for these
-purposes, rekeys have much the same properties as keepalives.
-(Except that rekeys have cryptographic value in themselves, so you
-should bear that in mind when deciding whether to turn them off.)
+Disabling data-based rekeys entirely is a bad idea. The integrity,
+and to a lesser extent, confidentiality of the SSH-2 protocol depend
+in part on rekeys occuring before a 32-bit packet sequence number
+wraps around. Unlike time-based rekeys, data-based rekeys won't occur
+when the SSH connection is idle, so they shouldn't cause the same
+problems. The SSH-1 protocol, incidentally, has even weaker integrity
+protection than SSH-2 without rekeys.
\H{config-ssh-auth} The Auth panel
This is an SSH2-specific bug.
+\S{config-ssh-bug-rekey} \q{Handles key re-exchange badly}
+
+\cfg{winhelp-topic}{ssh.bugs.rekey2}
+
+Some SSH servers cannot cope with repeat key exchange at
+all, and will ignore attempts by the client to start one. Since
+PuTTY pauses the session while performing a repeat key exchange, the
+effect of this would be to cause the session to hang after an hour
+(unless you have your rekey timeout set differently; see
+\k{config-ssh-kex-rekey} for more about rekeys).
+Other, very old, SSH servers handle repeat key exchange even more
+badly, and disconnect upon receiving a repeat key exchange request.
+
+If this bug is detected, PuTTY will never initiate a repeat key
+exchange. If this bug is enabled when talking to a correct server,
+the session should still function, but may be less secure than you
+would expect.
+
+This is an SSH2-specific bug.
+
\H{config-file} Storing configuration in a file
PuTTY does not currently support storing its configuration in a file
projects / u / mdw / putty / blobdiff