Understanding SSH

SSH servers offer the client a selection of authentication methods. The server advertises what it supports, and the client attempts to authenticate over each method that it can support. Generally, the client will choose methods that are the least intrusive to the user, if they are available. In most cases, the client provides the option to choose which methods can be used.

The actuall other of authentication methods is as follows: MIT Kerberos GSSAPI 5 (SSH2 only), public key (using PageAnt), public key (using configured file), keyboard-interactive (SSH2 only), TIS or Cryptocard, password.

Read Putty documentation. It mostly applies to WinSCP.

Read Putty documentation. It mostly applies to WinSCP.

A number of encryption methods can be used by SSH clients and servers. In the older SSH1 protocol, 3DES and DES are typically used. SSH2 adds support for additional encryption methods including AES and Blowfish. By default, AES is used if supported by the server. AES is considered to be highly secure, however substantial processor overhead is involved in performing AES encryption. Blowfish is also considered secure, but with less computational overhead, it’s also theoretically easier to perform a brute-force attack. Depending on your security and performance requirements, you may wish to configure WinSCP to prefer the Blowfish algorithm. 3DES and DES are used with SSH1 servers. DES is widely regarded as insecure, as the resources to perform an exhaustive brute-force attack have been well within the realm of commercial feasibility for some time.

Two major versions of the SSH protocol are in widespread use. The SSH1 protocol is an older version of the SSH protocol that’s still widely supported despite its age and some technical issues. The SSH2 protocol has become the de-facto standard for most installations, although there are still a few systems out there only supporting SSH1. Additionally, many sites that use SSH2 now disable the SSH1 protocol for security reasons.

The default setting in WinSCP is to prefer SSH2 and negotiate down to SSH1 if SSH2 is not available. If the majority of systems you connect to are using SSH2, you may wish to change this setting in the SSH preferences.

SSH supports compression of the data stream between the client and the server. On slow links, this may increase throughput, however, with faster connections the added CPU overhead may actually result in slower transfers, particularly depending on the type of data being transferred - large text files may still benefit significantly, while binaries transfer may actually transfer more slowly. You may wish to experiment to find what works best in your situation. Compression may also improve security slightly, in part by rendering known-cyphertext attacks more difficult to execute and by providing less data for cryptanalysis.