Differences
This shows you the differences between the selected revisions of the page.
| ui_login_kex 2023-02-13 | ui_login_kex 2023-05-24 (current) | ||
| Line 23: | Line 23: | ||
| WinSCP currently supports the following key exchange methods: | 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. &beta_feature | + | * //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. |
| * //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: | * //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. &beta_feature | + | * //Group 18//, a well-known 8192-bit group, used with the SHA-512 hash function. |
| - | * //Group 17//, a well-known 6144-bit group, used with the %%SHA-512%% hash function. &beta_feature | + | * //Group 17//, a well-known 6144-bit group, used with the %%SHA-512%% hash function. |
| - | * //Group 16//, a well-known 4096-bit group, used with the %%SHA-512%% hash function. &beta_feature | + | * //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. &beta_feature | + | * //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 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. | * //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. | ||
| Line 44: | Line 44: | ||
| 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".) | 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. | + | 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. | 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. | ||