SecureBlackbox 16: Introduction to SSH

Contents

• Secure Shell History and SSH vs. SSL
• SSH Basics
• SSH Tunnels
• Basics
• Shell and Command Tunnels
• Port Forwarding Tunnels
• Custom Tunnels
• SFTP

Secure Shell History and SSH vs. SSL

Secure Shell is a set of protocols (commonly referred to as SSH) for the secure transfer of data via insecure channels, such as TCP. SSH was initially designed as a secure replacement for the Unix rsh (remote shell) application. Reviewed below, these elements are apparent in various aspects of the SSH protocol design and implementation.

The SSH protocol exists in two versions, SSH 1 and SSH 2. SSH 1 was found to be vulnerable to several attacks and its use is not recommended.

The Secure Shell standards are currently maintained by SSH Communications Security Corp. and represented as IETF-secsh Internet-Drafts

Features of SSH

In its features, SSH is often compared to SSL/TLS. Both provide similar functionality (securing the data exchange using asymmetric keys); however, the differences are also significant.

• SSH expects the client to always authenticate to the server. Authentication can be done in various ways including explicit keyboard authentication.
• SSH is quite efficient when very small chunks of data (1-4 bytes) are sent. This is due to the fact that SSH was created to tunnel manual typing in remote shell access.

• SSH allows you to organize the so-called tunnels (independent channels of information exchange). For example, you can connect to a shell and a MySQL server after establishing a single SSH connection.

• SSH supports ZLib compression of the transferred data, which is not available in most SSL/TLS implementations (SSLBlackbox does support compression in SSL).

Comparing SSL Features

Compared with SSH, SSL is somewhat easier to understand and use. Also, SSH keys (the most commonly used method of SSH authentication) are stored in different, incompatible formats, while SSL certificates have a single predefined format (DER-encoded X.509 certificates and private keys).

Choosing SSL vs. SSH

When choosing to use SSL or SSH, you typically focus on the way the clients and servers recognize/authenticate each other; also decide, if you need to have independent data channels running over a single SSH connection.

SSH Basics

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

1. Handshake
2. Authentication
3. Data exchange

Handshake

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

Authentication

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

The following authentication methods are available for client authentication in SSH:

• Public key authentication (main authentication method)

  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

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

• Host-based authentication

  Host-based authentication is used to restrict client access only to certain hosts. 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 another host won't authenticate the client).

• Keyboard authentication

  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) are presented to the user. The user should give the answer to each prompt. The number and contents of the questions are virtually unlimited, so certain types of automated logins are also possible.

Data Exchange

The data exchange proceeds if the authentication was successful: in this phase, the client or server creates and manages one or more independent logical connections (data channels).

SSH Tunnels

Basics: Tunnels and Subsystems

A tunnel is an object that defines what logical connections should be established via a single SSH connection. Usually, a tunnel specifies exactly one connection, but in certain cases (e.g., port forwarding) there can be more than one connection established as defined by one tunnel.

SSH also uses the subsystem class, a scope of functions accessible via some tunnel. The tunnel usually describes a subsystem.

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

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

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

Shell and Command Tunnels

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

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

Port Forwarding Tunnels

This type of tunnel 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

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

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

Remote Port Forwarding

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

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

Custom Tunnels

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

SFTP

SFTP (SSH File Transfer Protocol) is a specialized subsystem for file transfer and remote file and folder manipulations. It is part of the SSH2 protocol family; however, some servers support it even with SSH1. SFTP supports the basic operations necessary for file management, but it is not as sophisticated as FTP, having less commands and features:

• SFTP doesn't have a "change working directory" function
• All file names must be either relative to the user's home folder (or the base folder of the server -- this depends on the configuration) or absolute. The standard recommends avoiding absolute paths for security purposes.