Introduction to SSH


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 (

In its 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.

2. SSH Basics

Without going deep into technical details, SSH connection consists of the following steps:

  1. Handshake
  2. Authentication
  3. Data exchange

During handshake phase the sides exchange information about SSH protocol version and used cipher suites (combinations of asymmetric encryption, symmetric encryption and hashing algorithms) and compression algorithm (none/ZLib at the moment). Unlike SSL, in SSH the server sends the first data block to the client.

First the server and client authenticate themselves to the other side. Server is authenticated using host key. The client is expected to store the key fingerprint somewhere and then validate the key next time (and notify the user if the fingerprint is different from the stored one). X.509 certificate can be used as a host key.

Client authentication in SSH can be done in one of the following ways:

  • Public key authentication(main authentication method)
  • Password authentication
  • Host-based authentication
  • Keyboard authentication

Public-key authentication is based on asymmetric cryptographic algorithms, where both client and server have key pairs and exchange public keys during the handshake.

Password authentication is a common plain-text authentication, where the client specifies his username and password as known for the server OS.

Host-based authentication is used to restrict client access only to certain host. This method is similar to public key authentication, however the server maintains a list of hosts and their public keys (so using the public key on other host won't authenticate the client).

Keyboard authentication is the advanced form of password authentication, aimed specifically at the human operator as a client. During keyboard authentication zero or more prompts (questions) is (are) presented to the user. The user should give the answer to each prompt (question). The number and contents of the questions are virtually not limited, so certain types of automated logins are also possible.

Data exchange is performed if the authentication was successful. For data exchange the client or server creates and manages one or more independent logical connections (data channels).

3. SSH Tunnels


Tunnel is an object, that defines, what logical connection(s) should be established via single SSH connection. Usually tunnel specifies exactly one connection, but in certain cases (ex. Port forwarding) there can be more than one connection established as defined by one tunnel.

Another class that SSH operates with is subsystem. Subsystem is a scope of functions, accessible via some tunnel. The tunnel usually describes a subsystem.

SSH defines the following types of subsystems (note that SSH specification itself calls this application, shell, system command or subsystem) :

  • Shell (remote terminal)
  • Command (execution of single system or shell command or application)
  • X11 tunneling (remote X11 access)
  • Custom subsystem (this includes SFTP, file transfer protocol)
  • Local port forwarding
  • Remote port forwarding

For programming purposes (when building a client-server system) custom subsystem is usually used. For remote shell access shell or command subsystems are used.

Shell and command tunnels

Shell and command tunnels are used to remotely access shell (usually Unix shell). Command tunnel executes exactly one command and directly tunnels input and output of remotely executed process. Command tunnel executes exactly one command and is closed after the command execution is finished.

Shell tunnel includes invocation of remote shell process (usually sh or bash in Unix) and sending commands to this process. Shell tunnel is kept alive for certain (long) time. It lets the client run several commands, but the client receives shell prompt text and should parse it to be able to correctly invoke remote commands. In other words shell tunnel sends exactly what you see and type when connecting to remote server using some console SSH tool.

Port forwarding tunnels

This type of tunnels was designed to provide secure tunneling for third-party applications. The idea behind port forwarding is described below from the client's point of view.

Local port forwarding:

  1. the application opens a port and listens to the socket
  2. when the client connects to this port, new logical connection is established with SSH server. SSH server is told to connect to certain address, specified in Tunnel settings (remember that tunnel is the object that defines settings for connections).
  3. the data sent by the client are forwarded to remote SSH server, which forwards them to specified address. The data received from remote SSH server are sent back to the client.

Local port forwarding is used to secure client-side connections.

Remote port forwarding:

  1. the application asks SSH server to open a port and listen to the socket.
  2. when the client connects to the port opened by SSH server, new logical connection is established with SSH server.
  3. SSH server forwards the data to the application. The application is then supposed to send the data wherever it needs. The data received by application from local point are supposed to be sent back to SSH server, which sends them back to remote side.

Remote port forwarding was designed especially for FTP Data channel, where remote FTP server needs to connect back to FTP client.

Custom tunnels

Custom tunnels are the ones used in custom applications for client-server data exchange. Custom tunnels are created by name and you can create any number of tunnels and connections of this kind.


SFTP (SSH File Transfer Protocol) is a specialized subsystem for file transfer and remote file and folder manipulations. It is part of SSH2 protocol family; however some servers support it even with SSH1. SFTP is not as sophisticated as FTP, i.e. it has less commands and features.

However it supports all basic operations, necessary for file management. SFTP doesn't have a "change working directory" function and all file names must be either relative to user's home folder (or base folder of the server, this depends on configuration) or absolute. The standard recommends avoiding absolute paths for security purposes.

Ready to get started?

Learn more about SecureBlackbox or download a free trial.

Download Now