Key Exchange Tab (Login Dialog)

Key exchange tab allows you to configure key exchange algorithm policy and key re-exchange options.

You need to check Advanced options to reveal the tab.

Key exchange occurs at the start of an SSH connection (and occasionally thereafter); it establishes a shared secret that is used as the basis for all of SSH's security features. It is therefore very important for the security of the connection that the key exchange is secure. (see note 1)

Key exchange is a cryptographically intensive process; if either the client or the server is a relatively slow machine, the slower methods may take several tens of seconds to complete.

If connection startup is too slow, or the connection hangs periodically, you may want to try changing these settings.

If you don't understand what any of this means, it's safe to leave these settings alone.

This entire panel is only relevant to SSH protocol version 2; none of these settings affect SSH-1 at all.

Key Exchange Algorithm Options

WinSCP supports a variety of SSH-2 key exchange methods, and allows you to choose which one you prefer to use; configuration is similar to cipher selection.

WinSCP currently supports the following varieties of Diffie-Hellman and GSSAPI key exchange:

• Group 14: a well-known 2048-bit group.
• Group 1: a well-known 1024-bit group. This is less secure than group 14, but may be faster with slow client or server machines, and may be the only method supported by older server software.
• Group exchange: with this method, instead of using a fixed group, WinSCP requests that the server suggest a group to use for key exchange; the server can avoid groups known to be weak, and possibly invent new ones over time, without any changes required to WinSCP's configuration. We recommend use of this method, if possible.

The GSSAPI varieties are used only when GSSAPI/SSPI authentication is used.

If the first algorithm WinSCP finds is below the warn below here line, you will see a warning box when you make the connection, similar to that for cipher selection.

Options Controlling Key Re-exchange

If the session key negotiated at connection startup is used too much or for too long, it may become feasible to mount attacks against the SSH connection. Therefore, the SSH-2 protocol specifies that a new key exchange should take place every so often; this can be initiated by either the client or the server.

While this renegotiation is taking place, no data can pass through the SSH connection, so it may appear to "freeze". Usually the same algorithm is used as at the start of the connection, with a similar overhead.

These options control how often WinSCP will initiate a repeat key exchange ("rekey").

Max minutes before rekey specifies the amount of time that is allowed to elapse before a rekey is initiated. If this is set to zero, WinSCP 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 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). Note, however, that the SSH server can still initiate rekeys.

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, WinSCP will not rekey due to transferred data. The SSH-2 protocol specification recommends a limit of at most 1 gigabyte.

As well as specifying a value in bytes, the following shorthand can be used:

• 1k specifies 1 kilobyte (1024 bytes).
• 1M specifies 1 megabyte (1024 kilobytes).
• 1G specifies 1 gigabyte (1024 megabytes).

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 occurring 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.

Notes:

1) The text is copy of PuTTY User Manual or was inspired by it.