Key exchange description
A SSH connection implies the use of several algorithms that, together, make the connection secure. There are several encryption, data integrity, key exchange, public key and compression algorithms to choose from. These choices are made between the client (Xceed SFtp for .NET) and the server during a phase called key exchange. Key exchange occurs immediately after a connection with the server is made. It also occurs during a session at regular intervals determined by the server.
An encryption algorithm and a key is negotiated during the key exchange. When encryption is in effect, all data, including meta-data like packet lengths and padding fields will be encrypted with the given algorithm.
Data integrity is protected by including with each packet a message authentication code (MAC) that is computed from a shared secret, packet sequence number, and the contents of the packet.
The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done.
A public key algorithm is used to provide a way to format, sign/encrypt, and encode the keys and certificates exchanged between the client and the server.
Packet data can optionally be compressed by the SSH protocol. Please note that at this time, compression is not supported by the component.
A list of all the algorithms supported by the component can be found in the technical overview section of the SFtp Capabilities page.
Key exchange is performed automatically and generally does not require input from the application with one exception that will be covered below.
Algorithm negotiation
With so many algorithms to chose from, the client and server decide together on which to use using a simple ordered list system. For each algorithm category, the client and server exchange a list of algorithms they support and want to use in order of preference. The chosen algorithm will be the first one that appear in both lists.
As an example, consider the following encryption algorithm lists. The client's list:
aes128-cbc, aes256-cbc, aes128-ctr, 3des-cbc, arcfour256, none
The server's list:
aes128-ctr, aes256-ctr, aes192-ctr
The first common algorithm is aes128-ctr and so that is the one that will be used for encryption. If no common algorithms are found, negotiation fails and both parties will disconnect.
Algorithm negotiation properties and methods
The technical overview section of the SFtp Capabilities page lists the algorithms the component supports and the order of preference in which they will be listed.
It is possible to alter the order of the algorithms that the client will expose or to remove algorithms altogether The SSHClient class contains properties that return SSHAlgorithmList objects. They encapsulate the lists and allow them to be manipulated.
Algorithm list manipulation example
AlgorithmsNegotiated event
The SSHClient class has a AlgorithmsNegotiated event. It is triggered after the algorithms lists have been exchanged between the server and the client and the objects that represent the negotiated algorithms have been constructed. It is an ideal place to set options for those algorithms that have them as the example below will demonstrate.
Is most situations, it is not necessary to handle the AlgorithmsNegotiated event as the default behavior is adequate. Applications should only use the event in advanced scenarios or when a specific options needs to be set for an algorithm object.
Algorithms negotiated event example