SshTunnel

set mySshTunnel [new CkSshTunnel]

When set to 1, causes the currently running method to abort. Methods that always finish quickly (i.e.have no length file operations or network communications) are not affected. If no method is running, then this property is automatically reset to 0 when the next method is called. When the abort occurs, this property is reset to 0. Both synchronous and asynchronous method calls can be aborted. (A synchronous method call could be aborted by setting this property from a separate thread.)

top

Contains an in-memory log of the listen thread. This will only contain content if the KeepAcceptLog property is 1.

top

Specifies a log file to be kept for the activity in the listen thread.

top

The client-identifier string to be used when connecting to an SSH/SFTP server. Starting in Chilkat v9.5.0.99, the default is "SSH-2.0-Chilkat_" + the Chilkat version number, such as "SSH-2.0-Chilkat_9.5.0.99".

Note: The client identifier should always begin with "SSH-2.0-". SSH servers may disconnect if it does not.

top

Maximum number of milliseconds to wait when connecting to an SSH server. The default value is 10000 (i.e. 10 seconds). A value of 0 indicates no timeout (wait forever).

top

If set to a file path, causes each Chilkat method or property call to automatically append it's LastErrorText to the specified log file. The information is appended such that if a hang or crash occurs, it is possible to see the context in which the problem occurred, as well as a history of all Chilkat calls up to the point of the problem. The VerboseLogging property can be set to provide more detailed information.

This property is typically used for debugging the rare cases where a Chilkat method call hangs or generates an exception that halts program execution (i.e. crashes). A hang or crash should generally never happen. The typical causes of a hang are:

1. a timeout related property was set to 0 to explicitly indicate that an infinite timeout is desired,
2. the hang is actually a hang within an event callback (i.e. it is a hang within the application code), or
3. there is an internal problem (bug) in the Chilkat code that causes the hang.

top

The destination hostname or IP address (in dotted decimal notation) of the service (such as a database server). Data sent through the SSH tunnel is forwarded by the SSH server to this destination. Data received from the destination (by the SSH server) is forwarded back to the client through the SSH tunnel.

top

The destination port of the service (such as a database server).

top

If 1, then this behaves as a SOCKS proxy server for inbound connections. When this property is 1, the DestHostname and DestPort properties are unused because the destination IP:port is dynamically provided by the SOCKS client. The default value of this property is 0.

When dynamic port forwarding is used, the InboundSocksVersion property must be set to 4 or 5. If inbound SOCKS5 is used, then the InboundSocksUsername and InboundSocksPassword may be set to the required login/password for a client to gain access.

top

Set after connecting to an SSH server. The format of the fingerprint looks like this: "ssh-rsa 1024 68:ff:d1:4e:6c:ff:d7:b0:d6:58:73:85:07:bc:2e:d5"

top

If an HTTP proxy requiring authentication is to be used, set this property to the HTTP proxy authentication method name. Valid choices are "Basic" or "NTLM".

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through an HTTP proxy.

top

The NTLM authentication domain (optional) if NTLM authentication is used w/ the HTTP proxy.

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through an HTTP proxy.

top

If an HTTP proxy is to be used, set this property to the HTTP proxy hostname or IPv4 address (in dotted decimal notation).

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through an HTTP proxy.

top

If an HTTP proxy requiring authentication is to be used, set this property to the HTTP proxy password.

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through an HTTP proxy.

top

If an HTTP proxy is to be used, set this property to the HTTP proxy port number. (Two commonly used HTTP proxy ports are 8080 and 3128.)

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through an HTTP proxy.

top

If an HTTP proxy requiring authentication is to be used, set this property to the HTTP proxy login name.

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through an HTTP proxy.

top

A tunnel will fail when progress for sending or receiving data halts for more than this number of milliseconds. The default value is 10,000 (which is 10 seconds). A timeout of 0 indicates an infinite wait time (i.e. no timeout).

top

If dynamic port forwarding is used, then this may be set to the password required for authenticating inbound connections.

top

If dynamic port forwarding is used, then this may be set to the username required for authenticating inbound connections. If no username is set, then the inbound connection needs no authentication.

top

1 if a background thread is running and accepting connections.

top

If 1, then an in-memory log of the listen thread is kept. The default value is 0.

top

If 1, then a log of the SSH tunnel thread activity is kept in memory. The default value is 0.

top

Provides information in HTML format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top

Provides information in plain-text format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top

Provides information in XML format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top

Indicate whether the last method call succeeded or failed. A value of 1 indicates success, a value of 0 indicates failure. This property is automatically set for method calls. It is not modified by property accesses. The property is automatically set to indicate success for the following types of method calls:

• Any method that returns a string.
• Any method returning a Chilkat object, binary bytes, or a date/time.
• Any method returning a standard boolean status value where success = 1 and failure = 0.
• Any method returning an integer where failure is defined by a return value less than zero.

Note: Methods that do not fit the above requirements will always set this property equal to 1. For example, a method that returns no value (such as a "void" in C++) will technically always succeed.

top

In most cases, this property does not need to be set. It is provided for cases where it is required to bind the listen socket to a specific IP address (usually for computers with multiple network interfaces or IP addresses). For computers with a single network interface (i.e. most computers), this property should not be set. For multihoming computers, the default IP address is automatically used if this property is not set.

top

If a port number equal to 0 is passed to BeginAccepting, then this property will contain the actual allocated port number used. Otherwise it is equal to the port number passed to BeginAccepting, or 0 if BeginAccepting was never called.

top

In most cases, this property does not need to be set. It is provided for cases where it is required to bind the socket that is to connect to the SSH server (in the background thread) to a specific IP address (usually for computers with multiple network interfaces or IP addresses). For computers with a single network interface (i.e. most computers), this property should not be set. For multihoming computers, the default IP address is automatically used if this property is not set.

top

Unless there is a specific requirement for binding to a specific port, leave this unset (at the default value of 0). (99.9% of all users should never need to set this property.)

top

If 1, then use IPv6 over IPv4 when both are supported for a particular domain. The default value of this property is 0, which will choose IPv4 over IPv6.

top

The SOCKS4/SOCKS5 hostname or IPv4 address (in dotted decimal notation). This property is only used if the SocksVersion property is set to 4 or 5).

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through a SOCKS4 or SOCKS5 proxy.

top

The SOCKS5 password (if required). The SOCKS4 protocol does not include the use of a password, so this does not apply to SOCKS4.

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through a SOCKS4 or SOCKS5 proxy.

top

The SOCKS4/SOCKS5 proxy port. The default value is 1080. This property only applies if a SOCKS proxy is used (if the SocksVersion property is set to 4 or 5).

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through a SOCKS4 or SOCKS5 proxy.

top

The SOCKS4/SOCKS5 proxy username. This property is only used if the SocksVersion property is set to 4 or 5).

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through a SOCKS4 or SOCKS5 proxy.

top

SocksVersion May be set to one of the following integer values:

0 - No SOCKS proxy is used. This is the default.
4 - Connect via a SOCKS4 proxy.
5 - Connect via a SOCKS5 proxy.

Note: This is for the outbound connection to the SSH server. It is used when the outbound connection to the SSH server must go through a SOCKS4 or SOCKS5 proxy.

top

Sets the receive buffer size socket option. Normally, this property should be left unchanged. The default value is 4194304.

This property can be increased if download performance seems slow. It is recommended to be a multiple of 4096.

top

Sets the send buffer size socket option. Normally, this property should be left unchanged. The default value is 262144.

This property can be increased if upload performance seems slow. It is recommended to be a multiple of 4096. Testing with sizes such as 512K and 1MB is reasonable.

top

Controls whether the TCP_NODELAY socket option is used for the underlying TCP/IP socket. The default value is 0. Setting this property equal to 1 disables the Nagle algorithm and allows for better performance when small amounts of data are sent.

top

Contains an in-memory log of the SSH tunnel thread. This will only contain content if the KeepTunnelLog property is 1.

top

Set to keep a log file of the SSH tunnel thread.

top

This is a catch-all property to be used for uncommon needs. This property defaults to the empty string, and should typically remain empty.

Can be set to a list of the following comma separated keywords:

• ForceUserAuthRsaSha1 - Introduced in v9.5.0.98. When doing public-key authentication, forces rsa-sha1 to be used for the userauth algorithm even if the server supports rsa-sha2-256, rsa-sha2-512, but still requires SHA1 for the userauth algorithm. Make sure to set this option before connecting to the server.
• NoKeepAliveIgnoreMsg - Introduced in v9.5.0.76. Prevents the default behavior of the SSH tunnel sending an "ignore" message every 20 seconds to keep an unused connection alive.
• no-weak-mac-algs - Introduced in v9.5.0.98. Removes all weaker MAC algorithms from the list offered to the SSH server when negotiating the connection parameters during a Connect. Specifically, removes hmac-sha1-96, hmac-sha1, hmac-md5, and hmac-ripemd160. Note: Stronger algorithms such as hmac-sha2-256, hmac-sha2-512, etc., will already be automatically chosen because they are given higher preference. The only way a weaker algorithm is chosen is if the SSH server ONLY supports weaker algorithms. This option would only be set if you explicitly want to avoid connecting to older SSH servers, or servers configured in some unusual way where only weaker algorithms are supported on the server (which is rare).
• ProtectFromVpn - Introduced in v9.5.0.80. On Android systems, will bypass any VPN that may be installed or active.
• +ssh-hmac-etm - Introduced in v9.5.0.97. Version 9.5.0.97 disabled the *-etm MAC algorithms to mitigate the Terrapin attack. Use this keyword to include the etm MAC algorithms.
• +chacha20-poly1305@openssh.com - Introduced in v9.5.0.97. To mitigate the Terrapin attack, chacha20-poly1305@openssh.com is no longer included by default. It can be re-added by adding this keyword.

top

When set to 1, all "const char *" arguments are interpreted as utf-8 strings. If set to 0 (the default), then "const char *" arguments are interpreted as ANSI strings. Also, when set to 1, and Chilkat method returning a "const char *" is returning the utf-8 representation. If set to 0, all "const char *" return values are ANSI strings.

top

If set to 1, then the contents of LastErrorText (or LastErrorXml, or LastErrorHtml) may contain more verbose information. The default value is 0. Verbose logging should only be used for debugging. The potentially large quantity of logged information may adversely affect peformance.

top

Version of the component/library, such as "9.5.0.94"

top

Authenticates with the SSH server using public-key authentication. The corresponding public key must have been installed on the SSH server for the username. Authentication will succeed if the matching privateKey is provided.

Important: When reporting problems, please send the full contents of the LastErrorText property to support@chilkatsoft.com.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the AuthenticatePk method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Authenticates with the SSH server using a login and password.

An SSH session always begins by first calling Connect to connect to the SSH server, and then calling either AuthenticatePw or AuthenticatePk to login.

Important: When reporting problems, please send the full contents of the LastErrorText property to support@chilkatsoft.com.
Note: To learn about how to handle password change requests, see the PasswordChangeRequested property (above).

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the AuthenticatePw method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Authentication for SSH servers that require both a password and private key. (Most SSH servers are configured to require one or the other, but not both.)

Important: When reporting problems, please send the full contents of the LastErrorText property to support@chilkatsoft.com.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the AuthenticatePwPk method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

The same as AuthenticatePw, except the login and password strings are passed in secure string objects.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the AuthenticateSecPw method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

The same as AuthenticatePwPk, except the login and password strings are passed in secure string objects.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the AuthenticateSecPwPk method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Starts a background thread for listening on listenPort. A new SSH tunnel is created and managed for each accepted connection. SSH tunnels are managed in a 2nd background thread: the SSH tunnel pool thread.

BeginAccepting starts a background thread that creates a socket, binds to the port, and begins listening. If the bind fails (meaning something else may have already bound to the same port), then the background thread exits. You may check to see if BeginAccepting succeeds by waiting a short time (perhaps 50 millisec) and then examine the IsAccepting property. If it is 0, then BeginAccepting failed.

Important: The listenPort must be a port number that nothing else on the local computer is listening on.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the BeginAccepting method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Closes the SSH tunnel and disconnects all existing clients. If waitForThreads is 1, the method will wait for the tunnel and client threads to exit before returning.

Returns 1 for success, 0 for failure.

top

Connects to the SSH server to be used for SSH tunneling.

Important: Make sure to call CloseTunnel when finished with the tunnel, such as before exiting your program.

Note: Chilkat automatically sends an "ignore" message every 20 seconds to keep the connection with the SSH server alive. This can be turned off by adding the "NoKeepAliveIgnoreMsg" to the UncommonOptions property.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the Connect method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Connects to an SSH server through an existing SSH connection. The ssh is an existing connected and authenticated SSH object. The connection to hostname:port is made through the existing SSH connection via port-forwarding. If successful, the connection is as follows: application => ServerSSH1 => ServerSSH2. (where ServerSSH1 is the ssh and ServerSSH2 is the SSH server at hostname:port) Once connected in this way, all communications are routed through ServerSSH1 to ServerSSH2. This includes authentication -- which means the application must still call one of the Authenticate* methods to authenticate with ServerSSH2.

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the ConnectThroughSsh method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Continues keyboard-interactive authentication with the SSH server. The response is typically the password. If multiple responses are required (because there were multiple prompts in the infoRequest XML returned by StartKeyboardAuth), then the response should be formatted as XML (as shown below) otherwise the response simply contains the single response string.

<response>
    <response1>response to first prompt</response1>
    <response2>response to second prompt</response2>
    ...
    <responseN>response to Nth prompt</responseN>
</response>

If the interactive authentication completed with success or failure, the XML response will be:

<success>success_message</success>

or

<error>error_message</error>

If additional steps are required to complete the interactive authentication, then an XML string that provides the name, instruction, and prompts is returned. The XML has the following format:

 	<infoRequest numPrompts="N">
	    <name>name_string</name>
	    <instruction>instruction_string</instruction>
	    <prompt1 echo="1_or_0">prompt_string</prompt1>
	    ...
	    <promptN echo="1_or_0">prompt_string</promptN>
	</infoRequest>

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the ContinueKeyboardAuth method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Disconnects all clients, keeping the SSH tunnel open. If waitForThreads is 1, the method will wait for the client threads to exit before returning.

Returns 1 for success, 0 for failure.

top

Returns the current state of existing tunnels in an XML string.

Returns 1 for success, 0 for failure.

top

Returns 1 if connected to the SSH server. Returns 0 if the connection has been lost (or was never established).

top

Loads the caller of the task's async method.

Returns 1 for success, 0 for failure.

top

Provides a way to specific the exact set of algorithms allowed for the connection.

Returns 1 for success, 0 for failure.

top

Begins keyboard-interactive authentication with the SSH server. Returns an XML string providing the name, instruction, and prompts. The XML has the following format:

 	<infoRequest numPrompts="N">
	    <name>name_string</name>
	    <instruction>instruction_string</instruction>
	    <prompt1 echo="1_or_0">prompt_string</prompt1>
	    ...
	    <promptN echo="1_or_0">prompt_string</promptN>
	</infoRequest>

If the authentication immediately succeeds because no password is required, or immediately fails, the XML response can be:

<success>success_message</success>

or

<error>error_message</error>

Returns 1 for success, 0 for failure.

top

Creates an asynchronous task to call the StartKeyboardAuth method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns NULL on failure

top

Stops the listen background thread. It is possible to continue accepting connections by re-calling BeginAccepting. If waitForThread is 1, the method will wait for the listen thread to exit before returning.

Returns 1 for success, 0 for failure.

top