Differences
This shows you the differences between the selected revisions of the page.
| 2005-04-05 | 2005-05-04 | ||
| putty=>winscp (martin) | 3.7.5 ssh version syntax (martin) | ||
| Line 13: | Line 13: | ||
| 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 SSH1 at all. | + | This entire panel is only relevant to SSH protocol version 2; none of these settings affect SSH-1 at all. |
| ===== Key Exchange Algorithm Options ===== | ===== Key Exchange Algorithm Options ===== | ||
| - | WinSCP supports a variety of SSH2 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 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 currently supports the following varieties of Diffie-Hellman key exchange: | WinSCP currently supports the following varieties of Diffie-Hellman key exchange: | ||
| Line 28: | Line 28: | ||
| ===== Options Controlling Key Re-exchange ===== | ===== 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 SSH2 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-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. | 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 34: | Line 34: | ||
| 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 SSH2 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-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, the the SSH server can still initiate rekeys. | 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, the 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 SSH2 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-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: | As well as specifying a value in bytes, the following shorthand can be used: | ||