The Key Exchange Page (Advanced Site Settings dialog)

WinSCP supports a variety of 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 key exchange methods:

• ECDH: elliptic curve Diffie-Hellman key exchange.
• 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 instead of the well-known groups, if possible.
• Group 14: Diffie-Hellman key exchange with a well-known 2048-bit group.
• RSA key exchange: this requires much less computational effort on the part of the client, and somewhat less on the part of the server, than Diffie-Hellman key exchange.
• Group 1: Diffie-Hellman key exchange with a well-known 1024-bit group. We no longer recommend using this method, and it’s not used by default; however, it may be the only method supported by very old server software.

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.

WinSCP supports a set of key exchange methods that also incorporates GSSAPI-based authentication. They are enabled with the Attempt GSSAPI key exchange checkbox.

WinSCP can only perform the GSSAPI-authenticated key exchange methods when using Kerberos V5, and not other GSSAPI mechanisms. If the user running WinSCP has current Kerberos V5 credentials, then WinSCP will select the GSSAPI key exchange methods in preference to any of the ordinary SSH key exchange methods configured in the preference list.

The advantage of doing GSSAPI authentication as part of the SSH key exchange is apparent when you are using credential delegation. The SSH key exchange can be repeated later in the session, and this allows your Kerberos V5 credentials (which are typically short-lived) to be automatically re-delegated to the server when they are refreshed on the client. (This feature is commonly referred to as “cascading credentials”.)

If your server doesn’t support GSSAPI key exchange, it may still support GSSAPI in the SSH user authentication phase. This will still let you log in using your Kerberos credentials, but will only allow you to delegate the credentials that are active at the beginning of the session; they can’t be refreshed automatically later, in a long-running session.

Another effect of GSSAPI key exchange is that it replaces the usual SSH mechanism of permanent host keys. So if you use this method, then you won’t be asked any interactive questions about whether to accept the server’s host key. Instead, the Kerberos exchange will verify the identity of the host you connect to, at the same time as verifying your identity to it.

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 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 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). See keepalives sectionfor 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, 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 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 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.

Read more about Login dialog and Advanced Site Settings dialog.