1. Secure Shell. History, comparison to SSL.
Secure Shell is a set of protocols (commonly referred to as SSH) for secure transfer of data via insecure channels, such as TCP. SSH was initially designed as a secure replacement of Unix rsh (remote shell) application. This has caused certain specifics in various aspects of SSH protocol design and implementation, which are reviewed below.
Secure Shell standards are currently maintained by SSH Communications Security Corp. and represented as IETF-secsh Internet-Drafts (http://www.ietf.org/ID.html).
In it's features SSH is often compared to SSL/TLS. Both provide the similar functionality (securing the data exchange using asymmetric keys), however the differences are also significant.
First of all, SSH expects the client to always authenticate to the server. Authentication can be done in various ways including explicit keyboard authentication.
Next, SSH is quite efficient, when very small chunks of data (1-4 bytes) are sent. This is caused by the fact that SSH was created to tunnel manual typing that happens in remote shell access.
Third benefit of SSH is that SSH allows to organize the so-called tunnels, i.e. independent channels of information exchange. For example you can connect to shell and MySQL server after establishing single SSH connection.
And the last but not the least - SSH supports ZLib compression of transferred data, which is not available in most SSL/TLS implementations (SSLBlackbox does support compression in SSL).
On the other hand, SSL is somewhat easier to understand and use. Also, SSH keys (most commonly used method of SSH authentication) are stored in different, incompatible formats; while SSL certificates have single predefined format (DER-encoded X.509 certificates and private keys).
So if you choose, what protocol (SSL or SSH) to use, you focus on the way the clients and servers recognize/authenticate each other and also decide if you need to have independent data channels running over a single SSH connection.
SSH protocol exists in two versions, SSH 1 and SSH 2. SSH 1 was found vulnerable to several attacks and its use is not recommended.