Differences
This shows you the differences between the selected revisions of the page.
| ui_login_kex 2016-01-20 | ui_login_kex 2023-05-24 (current) | ||
| Line 1: | Line 1: | ||
| - | ====== Key Exchange Page (Advanced Site Settings dialog) ====== | + | ====== The Key Exchange Page (Advanced Site Settings dialog) ====== |
| The //Key exchange page// on the [[ui_login_advanced|Advanced Site Settings dialog]] allows you to configure key exchange algorithm policy and key re-exchange options. | The //Key exchange page// on the [[ui_login_advanced|Advanced Site Settings dialog]] allows you to configure key exchange algorithm policy and key re-exchange options. | ||
| Line 14: | Line 14: | ||
| If you don't understand what any of this means, it's safe to leave these settings alone. | 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. | ||
| &toc_title_page_sections | &toc_title_page_sections | ||
| - | ===== Key Exchange Algorithm Options ===== | + | ===== [[algorithms]] 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 [[ui_login_ssh#encryption_options|cipher selection]]. | + | WinSCP supports a variety of key exchange methods, and allows you to choose which one you prefer to use; configuration is similar to [[ui_login_ssh#encryption_options|cipher selection]]. |
| WinSCP currently supports the following key exchange methods: | WinSCP currently supports the following key exchange methods: | ||
| - | * //ECDH//: elliptic curve Diffie-Hellman key exchange. | + | * //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. |
| - | * //Group 14//: Diffie-Hellman key exchange with a well-known 2048-bit group. | + | * //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 1//: Diffie-Hellman key exchange with 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 18//, a well-known 8192-bit group, used with the SHA-512 hash function. |
| - | * //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. | + | ····* //Group 17//, a well-known 6144-bit group, used with the %%SHA-512%% hash function. |
| - | * //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 16//, a well-known 4096-bit group, used with the %%SHA-512%% hash function. |
| + | * //Group 15//, a well-known 3072-bit group, used with the %%SHA-512%% hash function. | ||
| + | * //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 [[ui_login_ssh#encryption_options|cipher selection]]. | 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 [[ui_login_ssh#encryption_options|cipher selection]]. | ||
| + | |||
| + | ==== [[gssapi]] GSSAPI-based Key Exchange ==== | ||
| + | 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 [[ui_login_authentication#gssapi_delegation|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 [[ui_login_authentication#gssapi|//SSH > Authentication// page]]. | ||
| + | |||
| + | Another effect of GSSAPI key exchange is that it replaces the usual [[ssh_verifying_the_host_key|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. | ||
| ===== [[reexchange]] Options Controlling Key Re-exchange ===== | ===== [[reexchange]] 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. | + | 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. | 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. | ||
| Line 40: | Line 55: | ||
| These options control how often WinSCP will initiate a repeat key exchange ("rekey"). | 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. | + | //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). Note, however, that the SSH server can still initiate rekeys. | + | You might have a need to disable time-based rekeys completely for the same reasons that [[ui_login_connection#keepalives|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 [[ui_login_connection#keepalives|keepalives section]]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, 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. | + | //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: | As well as specifying a value in bytes, the following shorthand can be used: | ||
| Line 52: | Line 67: | ||
| * ''1G'' specifies 1 gigabyte (1024 megabytes). | * ''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 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. | + | 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. |
| ===== Further Reading ===== | ===== Further Reading ===== | ||
| Read more about [[ui_login|Login dialog]] and [[ui_login_advanced|Advanced Site Settings dialog]]. | Read more about [[ui_login|Login dialog]] and [[ui_login_advanced|Advanced Site Settings dialog]]. | ||