During the SSH handshake, this list will be used to negotiate the compression algorithm to be used between the client and server. This list is used for both directions: client to server and server to client. When negotiating algorithms, each side sends a list of all algorithms it supports or allows. The algorithm chosen for each direction is the first algorithm to appear in the sender's list that the receiver supports. Therefore, it is important to list multiple algorithms in preferential order. If no algorithm can be agreed on, the component will raise an error and the connection will be aborted.

At least one supported algorithm must appear in this list. The following compression algorithms are supported by the component:

• zlib
• zlib@openssh.com
• none

By default MaxChannelDataLength is 0 and ChannelDataEOL is an empty string. SSHChannelData fires whenever an SSH_MSG_CHANNEL_DATA packet is received.

If MaxChannelDataLength is greater than 0 and ChannelDataEOL is a nonempty string, the component will internally buffer data waiting to fire SSHChannelData until either MaxChannelDataLength is reached or ChannelDataEOL is found, whichever comes first. Query ChannelDataEOLFound to know which condition was met. The buffer is reset any time SSHChannelData fires.

ChannelDataEOL and MaxChannelDataLength must be set together or unexpected behavior could occur.

If true,then ChannelDataEOL was found. If false, then MaxChannelDataLength was reached.

This configuration setting is valid only when queried inside SSHChannelData, MaxChannelDataLength > 0, and ChannelDataEOL is nonempty.

This configuration setting specifies the Secure Shell (SSH) version string used by the component. The default value is "SSH-2.0-IPWorks SSH Client 2024".

Most SSH servers expect the SSH version string to have the expected format "SSH-protocol version-software version". See above for an example.

The default value is true. When set to false, the component will repeat authentication methods that have already been completed during multifactor authentication.

This configuration setting controls whether Pageant authentication is disabled, enabled, or required. When enabled or required, the component attempts to communicate with PuTTY's ssh-agent, called "Pageant", over shared memory to perform public key authentication. Possible values and the corresponding behavior is described as follows:

Example 1. Enabling Pageant: component.Config("EnablePageantAuth=1"); component.SSHUser = "sshuser"; component.SSHLogon("localhost", 22);

Note: This functionality is available only on Windows.

The default value is "True". If set to "False", the client will not ask for credentials delegation support during authentication.

Note: Even if the client asks for delegation, the server/KDC might not grant it, and authentication will still succeed.

This property may be set to the fully qualified (DNS) name of the kerberos realm (or Windows Active Directory domain name) to use during GSSAPI authentication. This can be used to force authentication with a given realm if the client and server machines are not part of the same domain.

This property can be set to specify the Service Principal Name (SPN) associated with the SSH service on the remote host. This will usually be in the form "host/fqdn.of.sshhost[@REALM]". If not specified, the component will assume the SPN is based on the value of the SSHHost property and the kerberos realm used for authentication.

This property allows you to specify the threshold, in the number of bytes, for the Secure Shell (SSH) key renegotiation. The default value for this property is set to 1 GB.

Example. Setting the Threshold to 500 MB: SSHComponent.Config("KeyRenegotiationThreshold=524288000")

This configuration setting controls the level of detail that is logged through the Log event. Possible values are as follows:

By default MaxChannelDataLength is 0 and ChannelDataEOL is an empty string. SSHChannelData fires whenever an SSH_MSG_CHANNEL_DATA packet is received.

If MaxChannelDataLength is greater than 0 and ChannelDataEOL is a nonempty string, the component will internally buffer data waiting to fire SSHChannelData until either MaxChannelDataLength is reached or ChannelDataEOL is found, whichever comes first. Query ChannelDataEOLFound to know which condition was met. The buffer is reset any time SSHChannelData fires.

ChannelDataEOL and MaxChannelDataLength must be set together or unexpected behavior could occur.

This configuration setting specifies the maximum size of an individual data packet, in bytes, that can be sent to the sender.

This configuration setting specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window.

Note: This value may be changed during the connection, but the window size can only be increased, not decreased.

This configuration setting specifies whether strict key exchange (strict kex) was negotiated during the SSH handshake. If strict kex is being used, then this will return "True". If strict kex is not being used, then this will return "False".

component.Config("NegotiatedStrictKex")

This configuration setting optionally specifies a pattern to be matched to the prompt received from the server during keyboard-interactive authentication. If a matching prompt is detected the component automatically responds to the prompt with the password specified by SSHPassword.

This provides an easy way to automatically reply to prompts with the password if one is presented by the server. The password will be autofilled in the Response parameter of the SSHKeyboardInteractive event in the case of a match.

The following special characters are supported for pattern matching:

If these characters need to be used as a literal in a pattern, then they must be escaped by surrounding them with brackets []. Note: "]" and "-" do not need to be escaped. See below for the escape sequences:

For example, to match the value [Something].txt, specify the pattern [[]Something].txt.

This configuration setting may be when using the diffie-hellman-group-exchange-sha1 or diffie-hellman-group-exchange-sha256 key exchange algorithms to control the preferred size, in bits, of the modulus (p) prime number to request from the server. Acceptable values are between 1024 and 8192.

If set to a positive value, this configuration setting defines the length of data records to be received. The component will accumulate data until RecordLength is reached and only then will it fire the DataIn event with data of length RecordLength. This allows data to be received as records of known length. This value can be changed at any time, including within the DataIn event.

The default value is 0, meaning this setting is not used.

This configuration setting will return the remote host's SSH version string, which can help when identifying problematic servers. This configuration setting is read-only.

When authenticating via public key authentication, this setting may be set to the certificate authority (CA) signed client's public key. This is useful when the server has been configured to trust client keys signed by a particular CA. For instance: component.Config("SignedSSHCert=ssh-rsa-cert-v01@openssh.com AAAAB3NzaC1yc2EAAAADAQABAAAB..."); The algorithm such as ssh-rsa-cert-v01@openssh.com in the previous string is used as part of the authentication process. To use a different algorithm, simply change this value. For instance, all of the following are acceptable with the same signed public key:

• ssh-rsa-cert-v01@openssh.com AAAAB3NzaC1yc2EAAAADAQABAAAB...
• rsa-sha2-256-cert-v01@openssh.com AAAAB3NzaC1yc2EAAAADAQABAAAB...
• rsa-sha2-512-cert-v01@openssh.com AAAAB3NzaC1yc2EAAAADAQABAAAB...

The default value is "False". Set this to "True" to accept any key presented by the server.

If the server's host key was signed by a CA, this configuration setting may be used to specify the CA's public key. If specified, the component will trust any server's host key that was signed by the CA. For instance: component.Config("SSHAcceptServerCAKey=ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...");

This configuration setting may be set to a comma-delimited collection of 16-byte MD5 fingerprints that should be accepted as the host's key. You may supply it by hex- encoding the values in the form "0a:1b:2c:3d". Example 2. Accepting Fingerprints: SSHClient.Config("SSHAcceptServerHostKeyFingerprint=0a:1b:2c:3d"); If the server's fingerprint matches one of the values supplied, the component will accept the host key.

This configuration setting controls which hash algorithm is used to calculate the hostkey's fingerprint, displayed when SSHServerAuthentication fires. Valid values are as follows:

• MD5
• SHA1
• SHA256 (default)

This configuration setting may be queried in SSHServerAuthentication to get the server hostkey's MD5 fingerprint.

This configuration setting may be queried in SSHServerAuthentication to get the server hostkey's SHA-1 fingerprint.

This configuration setting may be queried in SSHServerAuthentication to get the server hostkey's SHA-256 fingerprint.

This configuration setting specifies the maximum number of keep-alive packets to send when no response is received. Normally a response to a keep-alive packet is received right away. If no response is received, the component will continue to send keep-alive packets until SSHKeepAliveCountMax is reached. If this is reached, the component will assume the connection is broken and disconnect. The default value is 5.

This configuration setting specifies the number of seconds between keep alive packets. If set to a positive value, the component will send a SSH keep-alive packet after KeepAliveInterval seconds of inactivity. This configuration setting takes effect only when there is no activity; if any data are sent or received over the connection, it will reset the timer.

The default value is 0, meaning no keep alives will be sent.

Note: The SSHREVERSETUNNEL component uses a default value of 30.

This configuration setting may be used to specify the list of supported key exchange algorithms used during Secure Shell (SSH) negotiation. The value should contain a comma-separated list of algorithms. Supported algorithms are as follows:

• curve25519-sha256
• curve25519-sha256@libssh.org
• diffie-hellman-group1-sha1
• diffie-hellman-group14-sha1
• diffie-hellman-group14-sha256
• diffie-hellman-group16-sha512
• diffie-hellman-group18-sha512
• diffie-hellman-group-exchange-sha256
• diffie-hellman-group-exchange-sha1
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521
• gss-group14-sha256-toWM5Slw5Ew8Mqkay+al2g==
• gss-group16-sha512-toWM5Slw5Ew8Mqkay+al2g==
• gss-nistp256-sha256-toWM5Slw5Ew8Mqkay+al2g==
• gss-curve25519-sha256-toWM5Slw5Ew8Mqkay+al2g==
• gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==
• gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==

Once this configuration setting is queried, the component will renegotiate the SSH keys with the remote host.

Example 3. Renegotiating SSH Keys: SSHClient.Config("SSHKeyRenegotiate")

This configuration setting may be used to specify an alternate list of supported Mac algorithms used during SSH negotiation. This also specifies the order in which the Mac algorithms are preferred. The value should contain a comma-separated list of algorithms. Supported algorithms are as follows:

• hmac-sha1
• hmac-md5
• hmac-sha1-96
• hmac-md5-96
• hmac-sha2-256
• hmac-sha2-256-96
• hmac-sha2-512
• hmac-sha2-512-96
• hmac-ripemd160
• hmac-ripemd160-96
• hmac-sha2-256-etm@openssh.com
• hmac-sha2-512-etm@openssh.com
• hmac-sha2-256-96-etm@openssh.com
• hmac-sha2-512-96-etm@openssh.com
• umac-64@openssh.com
• umac-64-etm@openssh.com
• umac-128@openssh.com
• umac-128-etm@openssh.com

This setting specifies a list of signature algorithms that may be used when authenticating to the server using public key authentication. This applies only when public key authentication is performed by the client.

The setting should be a comma-separated list of algorithms. At runtime, the component will evaluate the specified algorithms, and if the algorithm is applicable to the certificate specified in SSHCert, it will be used. If the algorithm is not applicable, the component will evaluate the next algorithm. Possible values are as follows:

• ssh-rsa
• rsa-sha2-256
• rsa-sha2-512
• ssh-dss
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521
• ssh-ed25519
• x509v3-sign-rsa
• x509v3-sign-dss

The default value in Windows is ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519.

rsa-sha2-256 and rsa-sha2-512 notes

The component will query the server for supported algorithms when connecting. If the server indicates support for rsa-sha2-256 or rsa-sha2-512 and the algorithm is present in the list defined by this setting (as in the default value), that algorithm will be used instead of ssh-rsa even when ssh-rsa appears first in the list.

For the rsa-sha2-256 and rsa-sha2-512 algorithms to be automatically preferred, the server must support the ext-info-c mechanism. In practice, older servers do not support this, and in that case, ssh-rsa will be used because it appears first in the list. Newer servers do support this mechanism, and in that case, rsa-sha2-256 or rsa-sha2-512 will be used even though it appears after ssh-rsa.

This behavior has been carefully designed to provide maximum compatibility while automatically using more secure algorithms when connecting to servers that support them.

This configuration setting specifies the allowed public key algorithms for the server's public key. This list controls only the public key algorithm used when authenticating the server's public key. This list has no bearing on the public key algorithms that can be used by the client when performing public key authentication to the server. The default value is ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss,x509v3-sign-rsa,x509v3-sign-dss.

This configuration setting specifies the pattern used to accept or deny the remote host's SSH version string. It takes a comma-delimited list of patterns to match. The default value is "*SSH-1.99-*,*SSH-2.0-*" and will accept connections from SSH 1.99 and 2.0 hosts. As an example, the following value would accept connections for SSH 1.99, 2.0, and 2.99 hosts.

*SSH-1.99-*,*SSH-2.0-*,*SSH-2.99-*

The default value is false. When set to true, the component will try to authenticate using all methods that it has credentials for and the server supports.

This configuration setting controls whether strict key exchange (strict kex) is enabled to mitigate the Terrapin attack. When enabled, the component will indicate support for strict key exchange by automatically including the pseudo-algorithm kex-strict-c-v00@openssh.com for client components and kex-strict-s-v00@openssh.com for server components in the list of supported key exchange algorithms.

Because both client and server must implement strict key exchange to effectively mitigate the Terrapin attack, the component provides options to further control the behavior in different scenarios. Possible values for this setting are as follows:

This configuration setting controls whether the component will wait for a server response to the SSH_MSG_CHANNEL_CLOSE when disconnecting. When the component disconnects, it will first attempt to close all open channels by sending a SSH_MSG_CHANNEL_CLOSE for each channel. This configuration setting controls whether the component will wait for a server response after sending the messages.

When True (default), the component will wait for a response to the channel close message until the responses have been received, the server closes the connection, or Timeout seconds is reached.

When False, the component will still send the channel close messages, but it will not wait for a response and will proceed to close the connection.

This configuration setting controls whether to wait for the server to close the connection when SSHLogoff is called.

When set to True, the component will initiate the disconnection sequence by sending SSH_MSG_DISCONNECT, but it will not close the connection and instead will wait for the server to close the connection. Setting this to True may be beneficial in circumstances in which many connections are being established, to avoid port exhaustion when sockets are in a TIME_WAIT state. Allowing the server to close the connection avoids the TIME_WAIT state of socket on the client machine.

When set to False (default), the client will close the connection. It is recommended to use this value unless there is a specific need to change it.

This configuration setting determines whether the input or output stream is closed after the transfer completes. When set to True (default), all streams will be closed after a transfer is completed. To keep streams open after the transfer of data, set this to False. The default value is True.

When set, this configuration setting allows you to specify a different timeout value for establishing a connection. Otherwise, the component will use Timeout for establishing a connection and transmitting/receiving data.

This configuration setting is provided for use by components that do not directly expose Firewall properties.

If a FirewallHost is given, requested connections will be authenticated through the specified firewall when connecting.

If the FirewallHost setting is set to a Domain Name, a DNS request is initiated. Upon successful termination of the request, the FirewallHost setting is set to the corresponding address. If the search is not successful, an error is returned.

Note: This setting is provided for use by components that do not directly expose Firewall properties.

This entry is for TCPClient only and does not work for other components that descend from TCPClient.

If this entry is set, the component acts as a server. RemoteHost and RemotePort are used to tell the SOCKS firewall in which address and port to listen to. The firewall rules may ignore RemoteHost, and it is recommended that RemoteHost be set to empty string in this case.

RemotePort is the port in which the firewall will listen to. If set to 0, the firewall will select a random port. The binding (address and port) is provided through the ConnectionStatus event.

The connection to the firewall is made by calling the Connect method.

If FirewallHost is specified, the FirewallUser and FirewallPassword settings are used to connect and authenticate to the given firewall. If the authentication fails, the component throws an exception.

Note: This setting is provided for use by components that do not directly expose Firewall properties.

The FirewallPort is set automatically when FirewallType is set to a valid value.

Note: This configuration setting is provided for use by components that do not directly expose Firewall properties.

Possible values are as follows:

Note: This setting is provided for use by components that do not directly expose Firewall properties.

If the FirewallHost is specified, the FirewallUser and FirewallPassword settings are used to connect and authenticate to the Firewall. If the authentication fails, the component throws an exception.

Note: This setting is provided for use by components that do not directly expose Firewall properties.

When set, TCPKeepAlive will automatically be set to True. A TCP keep-alive packet will be sent after a period of inactivity as defined by KeepAliveTime. If no acknowledgment is received from the remote host, the keep-alive packet will be sent again. This configuration setting specifies the interval at which the successive keep-alive packets are sent in milliseconds. This system default if this value is not specified here is 1 second.

Note: This value is not applicable in macOS.

When set, TCPKeepAlive will automatically be set to True. By default, the operating system will determine the time a connection is idle before a Transmission Control Protocol (TCP) keep-alive packet is sent. This system default if this value is not specified here is 2 hours. In many cases, a shorter interval is more useful. Set this value to the desired interval in milliseconds.

This property controls how a connection is closed. The default is True.

In the case that Linger is True (default), two scenarios determine how long the connection will linger. In the first, if LingerTime is 0 (default), the system will attempt to send pending data for a connection until the default IP timeout expires.

In the second scenario, if LingerTime is a positive value, the system will attempt to send pending data until the specified LingerTime is reached. If this attempt fails, then the system will reset the connection.

The default behavior (which is also the default mode for stream sockets) might result in a long delay in closing the connection. Although the component returns control immediately, the system could hold system resources until all pending data are sent (even after your application closes).

Setting this property to False forces an immediate disconnection. If you know that the other side has received all the data you sent (e.g., by a client acknowledgment), setting this property to False might be the appropriate course of action.

LingerTime is the time, in seconds, the socket connection will linger. This value is 0 by default, which means it will use the default IP timeout.

The LocalHost setting contains the name of the local host as obtained by the gethostname() system call, or if the user has assigned an IP address, the value of that address.

In multihomed hosts (machines with more than one IP interface), setting LocalHost to the value of an interface will make the component initiate connections (or accept in the case of server components) only through that interface.

If the component is connected, the LocalHost setting shows the IP address of the interface through which the connection is made in internet dotted format (aaa.bbb.ccc.ddd). In most cases, this is the address of the local host, except for multihomed hosts (machines with more than one IP interface).

This configuration setting must be set before a connection is attempted. It instructs the component to bind to a specific port (or communication endpoint) in the local machine.

Setting this to 0 (default) enables the system to choose a port at random. The chosen port will be shown by LocalPort after the connection is established.

LocalPort cannot be changed once a connection is made. Any attempt to set this when a connection is active will generate an error.

This configuration setting is useful when trying to connect to services that require a trusted port on the client side. An example is the remote shell (rsh) service in UNIX systems.

MaxLineLength is the size of an internal buffer, which holds received data while waiting for an EOL string.

If an EOL string is found in the input stream before MaxLineLength bytes are received, the DataIn event is fired with the EOL parameter set to True, and the buffer is reset.

If no EOL is found, and MaxLineLength bytes are accumulated in the buffer, the DataIn event is fired with the EOL parameter set to False, and the buffer is reset.

The minimum value for MaxLineLength is 256 bytes. The default value is 2048 bytes.

This configuration setting can be used to throttle outbound TCP traffic. Set this to the number of bytes to be sent per second. By default, this is not set and there is no limit.

This configuration setting optionally specifies a semicolon-separated list of hostnames or IP addresses to bypass when a proxy is in use. When requests are made to hosts specified in this property, the proxy will not be used. For instance:

www.google.com;www.nsoftware.com

If set to True, the socket's keep-alive option is enabled and keep-alive packets will be sent periodically to maintain the connection. Set KeepAliveTime and KeepAliveInterval to configure the timing of the keep-alive packets.

Note: This value is not applicable in Java.

When set to True, the socket will send all data that are ready to send at once. When set to False, the socket will send smaller buffered packets of data at small intervals. This is known as the Nagle algorithm.

By default, this configuration setting is set to False.

When set to 0 (default), the component will use IPv4 exclusively. When set to 1, the component will use IPv6 exclusively. To instruct the component to prefer IPv6 addresses, but use IPv4 if IPv6 is not supported on the system, this setting should be set to 2. The default value is 0. Possible values are as follows:

When authenticating with NTLM, this setting specifies whether NTLM V2 is used. By default this value is False and NTLM V1 will be used. Set this to True to use NTLM V2.

If AbsoluteTimeout is set to True, any method that does not complete within Timeout seconds will be aborted. By default, AbsoluteTimeout is False, and the timeout is an inactivity timeout.

Note: This option is not valid for User Datagram Protocol (UDP) ports.

When the firewall is a tunneling proxy, use this property to send custom (additional) headers to the firewall (e.g., headers for custom authentication schemes).

This is the size of an internal queue in the Transmission Control Protocol (TCP)/IP stack. You can increase or decrease its size depending on the amount of data that you will be receiving. In some cases, increasing the value of the InBufferSize setting can provide significant improvements in performance.

Some TCP/IP implementations do not support variable buffer sizes. If that is the case, when the component is activated the InBufferSize reverts to its defined size. The same happens if you attempt to make it too large or too small.

This is the size of an internal queue in the TCP/IP stack. You can increase or decrease its size depending on the amount of data that you will be sending. In some cases, increasing the value of the OutBufferSize setting can provide significant improvements in performance.

Some TCP/IP implementations do not support variable buffer sizes. If that is the case, when the component is activated the OutBufferSize reverts to its defined size. The same happens if you attempt to make it too large or too small.

When queried, this setting will return a string containing information about the product's build.

In a GUI-based application, long-running blocking operations may cause the application to stop responding to input until the operation returns. The component will attempt to discover whether or not the application has a message loop and, if one is discovered, it will process events in that message loop during any such blocking operation.

In some non-GUI applications, an invalid message loop may be discovered that will result in errant behavior. In these cases, setting GUIAvailable to false will ensure that the component does not attempt to process external events.

When queried, this setting will return a string containing information about the license this instance of a component is using. It will return the following information:

• Product: The product the license is for.
• Product Key: The key the license was generated from.
• License Source: Where the license was found (e.g., RuntimeLicense, License File).
• License Type: The type of license installed (e.g., Royalty Free, Single Server).
• Last Valid Build: The last valid build number for which the license will work.

In certain circumstances it may be beneficial to mask sensitive data, like passwords, in log messages. Set this to true to mask sensitive data. The default is true.

This setting only works on these components: AS3Receiver, AS3Sender, Atom, Client(3DS), FTP, FTPServer, IMAP, OFTPClient, SSHClient, SCP, Server(3DS), Sexec, SFTP, SFTPServer, SSHServer, TCPClient, TCPServer.

When set to true, the component will utilize the underlying operating system's certified APIs. Java editions, regardless of OS, utilize Bouncy Castle Federal Information Processing Standards (FIPS), while all other Windows editions make use of Microsoft security libraries.

FIPS mode can be enabled by setting the UseFIPSCompliantAPI configuration setting to true. This is a static setting that applies to all instances of all components of the toolkit within the process. It is recommended to enable or disable this setting once before the component has been used to establish a connection. Enabling FIPS while an instance of the component is active and connected may result in unexpected behavior.

For more details, please see the FIPS 140-2 Compliance article.

Note: This setting is applicable only on Windows.

Note: Enabling FIPS compliance requires a special license; please contact sales@nsoftware.com for details.

When set to false, the component will use the system security libraries by default to perform cryptographic functions where applicable. In this case, calls to unmanaged code will be made. In certain environments, this is not desirable. To use a completely managed security implementation, set this setting to true.

Setting this configuration setting to true tells the component to use the internal implementation instead of using the system security libraries.

On Windows, this setting is set to false by default. On Linux/macOS, this setting is set to true by default.

If using the .NET Standard Library, this setting will be true on all platforms. The .NET Standard library does not support using the system security libraries.

Note: This setting is static. The value set is applicable to all components used in the application.

When this value is set, the product's system dynamic link library (DLL) is no longer required as a reference, as all unmanaged code is stored in that file.