Xceed .NET Libraries Documentation
'DeclarationPublic Class SSHTransportLayerProtocol Inherits Xceed.SSH.Core.SSHProtocol Implements Xceed.SSH.Core.ISSHPacketReceiver, Xceed.SSH.Core.ISSHPacketSender, Xceed.SSH.Core.ISSHProtocol, Xceed.SSH.Core.ISSHSequenceNumberGenerator, ISSHTransportLayerProtocol
'UsageDim instance As SSHTransportLayerProtocol
public class SSHTransportLayerProtocol : Xceed.SSH.Core.SSHProtocol, Xceed.SSH.Core.ISSHPacketReceiver, Xceed.SSH.Core.ISSHPacketSender, Xceed.SSH.Core.ISSHProtocol, Xceed.SSH.Core.ISSHSequenceNumberGenerator, ISSHTransportLayerProtocol
System.Object
Xceed.SSH.Core.SSHProtocol
Xceed.SSH.Protocols.SSHTransportLayerProtocol
| Name | Description | |
|---|---|---|
 | SSHTransportLayerProtocol Constructor |
| Name | Description | |
|---|---|---|
 | MaximumPaddingLength | |
| MinimumCipherBlockSize | |
| MinimumPacketSize | |
| MinimumPaddingLength | |
| PacketLengthSize | |
| PaddingLengthOffset | |
| PaddingLengthSize | |
| PayloadOffset | |
| WritePacketBufferSize |
| Name | Description | |
|---|---|---|
 | Connect | (Inherited from Xceed.SSH.Core.SSHProtocol) |
 | DefaultChooseAlgorithm | Overloaded. |
| DeriveKeys | RFC 4253: 7.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we'll call it HASH. |
| Disconnect | (Inherited from Xceed.SSH.Core.SSHProtocol) |
| FitKey | RFC 4253: 7.2. Output from Key Exchange |
| KeyExchange | Overloaded. RFC 4253: Section 7. KeyExchange Key exchange (kex) begins by each side sending name-lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations, at any given time, will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm, if appropriate for the preferred method. The guess is considered wrong if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section 7.1). Otherwise, the guess is considered to be right, and the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. A key exchange method uses explicit server authentication if the key exchange messages include a signature or other proof of the server's authenticity. A key exchange method uses implicit server authentication if, in order to prove its authenticity, the server also has to prove that it knows the shared secret, K, by sending a message and a corresponding MAC that the client can verify. The key exchange method defined by this document uses explicit server authentication. However, key exchange methods with implicit server authentication MAY be used with this protocol. After a key exchange with implicit server authentication, the client MUST wait for a response to its service request message before sending any further data. |
| ProtocolVersionExchange | RFC 4253: Section 4.2. Protocol Version Exchange |
| ReadPacket | |
| RequestService | 10. Service Request After the key exchange, the client requests a service. The service is identified by a name. The format of names and procedures for defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS]. If the server rejects the service request, it SHOULD send an appropriate SSH_MSG_DISCONNECT message and MUST disconnect. When the service starts, it may have access to the session identifier generated during the key exchange. |
| SimulateRemoteDisconnect | Overloaded. |
| UseNewKeys | |
| UseNewKeysClientToServer | RFC4253: 7.3. Taking Keys Into Use Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. When this message is received, the new keys and algorithms MUST be used for receiving. The purpose of this message is to ensure that a party is able to respond with an SSH_MSG_DISCONNECT message that the other party can understand if something goes wrong with the key exchange. |
| UseNewKeysServerToClient | RFC4253: 7.3. Taking Keys Into Use Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. When this message is received, the new keys and algorithms MUST be used for receiving. The purpose of this message is to ensure that a party is able to respond with an SSH_MSG_DISCONNECT message that the other party can understand if something goes wrong with the key exchange. |
| WritePacket |
| Name | Description | |
|---|---|---|
 | AlgorithmsNegotiated | |
| Disconnected | |
| HostKeyReceived |
.NET: net5.0, net5.0-windows, net6.0, net6.0-macos, net6.0-windows, net7.0, net7.0-macos, net7.0-windows, net8.0, net8.0-browser, net8.0-macos, net8.0-windows, net9.0, net9.0-browser, net9.0-macos, net9.0-windows, net10.0, net10.0-browser, net10.0-macos, net10.0-windows.
.NET Standard: netstandard2.0, netstandard2.1
.NET Framework: net20, net35, net40, net403, net45, net451, net452, net46, net461, net462, net463, net47, net471, net472, net48, net481.
