SSHSCPClient Class

public class SSHSCPClient : IExFileTransferClient, 
	IFileTransferClient

Public Class SSHSCPClient
	Implements IExFileTransferClient, IFileTransferClient

public ref class SSHSCPClient : IExFileTransferClient, 
	IFileTransferClient

type SSHSCPClient = 
    class
        interface IExFileTransferClient
        interface IFileTransferClient
    end

Inheritance

Object    SSHSCPClient

Derived

EnterpriseDT.Net.Ftp.SshSSHFTPClient

Implements

IExFileTransferClient, IFileTransferClient

SSHSCPClient supports SOCKS (4, 4A, and 5) and SFTP.

SSHSCPClient supports SFTP, which stands for SSH File Transfer Protocol. Essentially, it is file transfer over an SSH connection, hence it has the security of SSH. SFTP is only superficially related to FTP and FTPS. It achieves the same goals of file transfer and related operations, but the underlying protocol is entirely different.

Example

// create an SCP client
SSHSCPClient ftp = new SSHSCPClient();
ftp.RemoteHost = "192.168.10.123";

// Turn off server validation (ONLY do this when testing)
ftp.ServerValidation = SecureFTPServerValidationType.None;

// set up the credentials for password authentication (the default)
ftp.UserName = "myuser";
ftp.Password = "mypassword";

// connect to the server
ftp.Connect();                        

// get a file
ftp.Get("file.txt", "file.txt");

// close the connection
ftp.Quit();

This example uses password authentication and does not attempt to verify the server (which should always be done in production systems).

Server Validation: The examples above used no server validation. This is only normally acceptable only when testing. To be secure applications should always validate the server that they're communicating with. If the ServerValidation property is set to SecureFTPServerValidationType.Automatic or SecureFTPServerValidationType.AutomaticIgnoreHostName then SSHSCPClient will attempt to validate the server's public key upon connection.

Public keys are managed by the KnownHostsManager, available in the KnownHosts property. There are two ways that the client can load server public keys - via the known_hosts file or by explicitly loading a public key from a file.

1. Known_hosts – Many SSH implementations use a file called known_hosts which is loaded by clients to validate servers. Typically, this file is generated when the client first connects to a server - a prompt asks if the server should be added to the list of known hosts. The known_hosts file contains a list of approved servers and their public keys. The KnownHostsManager has a property called KnownHostsFile. The path of the known_hosts file should be assigned to this property to load the known hosts in that file.
2. Public key files – Server public keys can also be maintained in their own key file and be used for server validation without adding them to the known_hosts file. The KnownHostsManager supports explicitly adding server public keys via the AddKnownHost(String, String) method. This requires the hostname and the public key file. SSH public key files have two standard formats - OpenSSH and SECSH. Both these public key formats are supported.

Client Validation: Client authentication can be either by password, by public/private keys, or by keyboard- interactive authentication. The default is password authentication. The current authentication method can be found (and set) from the AuthenticationMethod property.

1. Password authentication – In password authentication, the UserName and Password properties must be set, along with the ServerAddress. The user name and password should be that of the SSH user that the client is logging in as. Note that some SFTP servers are set up to disallow password authentication, in which case the connection attempt will fail unless password authentication is enabled in the server configuration file.
2. Public key authentication – In public key authentication, SSH clients and servers authenticate each other via public/private key pairs. Each must have access to their own private key, and they must have access to each other's public key. The client's public key must be registered with the SSH server, typically by copying it into the server's authorized_keys file. The client's private key is loaded via the ClientPrivateKeyFile property. Both DSA and RSA keypairs can be used. The UserName and Password properties must be set, along with the RemoteHost. Here the password is the passphrase of the private key file. The AuthenticationMethod property must also be set to PublicKey. There are no formal standards for SSH private key files, however two main formats are in common use - ssh.com and OpenSSH. Both are supported.
3. Keyboard-interactive authentication – Keyboard-interactive (KBI) authentication is the most recently introduced form of authentication for SSH. It involves the server sending prompts to the client, which the client must respond to correctly to be authenticated. Its purpose is permit the client to support a variety of authentication mechanisms without knowing anything about them. This implementation of KBI authentication relies on the programmer knowing the prompts in advance. The prompts are easily determined by connecting to the server via a command-line ssh client, using KBI. when the server sends its list of prompts that require responses, the client searches the list of loaded SSHAuthPrompts for each prompt. It then sends the set responses back to the server. If the expected responses are supplied, the authentication succeeds. If the prompt is for a user's password, it will typically be something like "Password:". The SSHPasswordPrompt class is supplied to make it easier to set up a password prompt. To set up the prompts, an array of SSHAuthPrompts is assigned to the KBIPrompts property. Note that to use KBI, the AuthenticationMethod property must also be set to KeyboardInteractive.

Server Compatibility: Generally, this class should work with most SCP servers. Some servers return an error saying the file does not exist after creating it. By default, the client does a permission change after creating the file, which is done to ensure the file permissions are correct. If this error is encountered, try setting the ServerCompatibility property to SSHDisableChmodAfterPut to try to eliminate the problem.

Public key algorithms: Either DSA or RSA or both can be set for the preferred public key algorithms for server authentication. If, for example, RSA is set, the server will present an RSA public key to the client (if the server supports RSA keys of course - some servers do not). The PreferredHostKeyAlgorithms property is a bitwise flag and can be set to combinations of the SSHPublicKeyAlgorithm enum values by OR'ing them together. The default is all algorithms enabled.

Cipher algorithms: The cipher algorithms are the symmetric algorithms used to perform the encryption of the SFTP data and commands. The PreferredCipherAlgorithms property is a bitwise flag and can be set to combinations of the SSHCipherAlgorithm enum values by OR'ing them together. The default is all algorithms enabled.

SOCKS: SOCKS may be used for FTPing through firewalls. For this to be possible a SOCKS proxy must be available, and a user account must be set up on that proxy. SSLFTPClient supports all the popular versions of SOCKS - 4, 4A, and 5.

The SOCKS features are controlled entirely through the SocksContext property. If it is null (the default) then SOCKS is not used. To use SOCKS, the property must be set to an instance of Socks4Context or Socks5Context. For example, for SOCKS4:

Reference