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:

• NTRU Prime / Curve25519 hybrid: Streamlined NTRU Prime is a lattice-based algorithm intended to resist quantum attacks. In this key exchange method, it is run in parallel with a conventional Curve25519-based method (one of those included in ECDH, in such a way that it should be no less secure than that commonly-used method, and hopefully also resistant to a new class of attacks. This feature is available only in the latest beta release.
• ECDH: elliptic curve Diffie-Hellman key exchange, with a variety of standard curves and hash algorithms.
  The original form of Diffie-Hellman key exchange, with a variety of well-known groups and hashes:
  • Group 18, a well-known 8192-bit group, used with the SHA-512 hash function. This feature is available only in the latest beta release.
  • Group 17, a well-known 6144-bit group, used with the SHA-512 hash function. This feature is available only in the latest beta release.
  • Group 16, a well-known 4096-bit group, used with the SHA-512 hash function. This feature is available only in the latest beta release.
  • Group 15, a well-known 3072-bit group, used with the SHA-512 hash function. This feature is available only in the latest beta release.
  • Group 14: a well-known 2048-bit group, used with the SHA-256 hash function or, if the server doesn’t support that, SHA-1.
  • Group 1 : a well-known 1024-bit group, used with the SHA-1 hash function. Neither we nor current SSH standards recommend using this method any longer, and it’s not used by default in new installations; however, it may be the only method supported by very old server software.
• Diffie-Hellman group exchange: with this method, instead of using a fixed group, WinSCP requests that the server suggest a group to use for a subsequent Diffie-Hellman 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. This key exchange method uses the SHA-256 hash or, if the server doesn’t support that, SHA-1.
• RSA-based 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. There’s a GSSAPI-based equivalent to most of the ordinary methods listed is the previous section; server support determines which one will be used. (WinSCP’s preference order for GSSAPI-authenticated key exchange methods is fixed, not controlled by 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. The GSSAPI authentication can be configured on the SSH > Authentication page.

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.