Differences
This shows you the differences between the selected revisions of the page.
| 2021-12-06 | 2021-12-06 | ||
| removing reference to deprecated ssh-1 (martin) | no need to refer to ssh versions (martin) | ||
| Line 19: | Line 19: | ||
| ===== [[algorithms]] 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: | ||
| Line 43: | Line 43: | ||
| ===== [[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 49: | Line 49: | ||
| 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 [[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. | 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 61: | Line 61: | ||
| * ''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 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. | + | 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]]. | ||