The Internet makes it possible to carry out a wide variety of remote operations, and particularly server administration and file transfers. The Telnet protocol and the BSD r-commands (rsh, rlogin and rexec) that let users perform these remote tasks have the major disadvantage of circulating exchanged information in plaintext on the network, and particularly the login and password to access the remote machine. As such, a hacker who is located on a network between the user and the remote machine can monitor traffic, that is, use a tool called a sniffer that can capture packets circulating on the network and obtain the login and password to access the remote machine.

Even if the exchanged information does not have a high security level, the hacker obtains access to an account on the remote machine and can possibly escalate his privileges on the machine to obtain root access.

Given that it is impossiblie to control all physical infrastructures located between the user and the remote machine (the Internet being an open network by definition), the only solution is to rely on security at the logical level (at the data level).

The SSH (Secure Shell) protocol is a response to this problem in that it enables users (or TCP/IP services) to access a machine via an encrypted communication (called a tunnel).

The SSH protocol

The SSH (Secure Shell) protocol was developed in 1995 by Tatu Ylönen, from Finland.

It is a protocol that makes it possible for a client (a user or even a machine) to open an interactive session on a remote machine (server) to send commands or files over a secure channel:

• The data circulating between the client and the server are encrypted, which guarantees their confidentiality (nobody other than the server and the client can read the information being sent on the network). As a result, it is not possible to monitor the network with a sniffer.
• The client and server authenticate one another in order to make sure the two communicating machines are indeed those the parties believe them to be. A hacker can no longer take on the identity of the client or server (spoofing).

The goal of version 1 of the protocol (SSH1), which was proposed in 1995, was to offer an alternative to interactive sessions (shells) such as Telnet, rsh, rlogin and rexec. Yet this protocol had a flaw that enabled hackers to insert data in encrypted flows. This is why version 2 of the protocol (SSH2) was proposed in 1997 as a draft to the IETF. The documents defining the protocol can be accessed online at http://www.ietf.org/html.charters/secsh-charter.html.

Secure Shell Version 2 also includes a Secure File Transfer Protocol (SFTP).

SSH is a protocol, that is, a standard method enabling machines to establish a secure connection. As such, there are a variety of SSH client and server implementations. Some require a fee, while others are free or open source: you will find a certain number of SSH clients in the downloading section of CommentCaMarche.

How SSH works

An SSH connection is established in several phases:

• Firstly, the server and client identify one another in order to establish a secure channel (secure transport layer).
• Secondly, the client logs in to the server to obtain a session.

Establishing a secure channel

The establishment of a secure transport layer starts with a negotation phase between the client and server so they can agree on the encryption methods they want to use. The SSH protocol is designed to work with a large number of encryption algorithms, which is why the client and server must first exchange the algorithms they support.

Next, to establish a secure connection, the server sends its host key to the client. The client generates a 256-bit session key it encrypts with the server's public key, and sends the server the encrypted session key as well as the algorithm used. The server decrypts the session key with its private key and sends a confirmation message encrypted with the session key. After this point, the remaining communications are encrypted thanks to a symmetric encryption algorithm using the session key shared by the client and the server.

The transaction's security is based on the client and server's confidence that the other party's host keys are valid. As such, when first connecting to a server, the client generally displays a message asking to accept the connection (and possibly presents a hash of the server's host key):

Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?

In order to obtain a truly secure session, it is best to verbally ask the server's administrator to validate the public key presented. If the user validates the connection, the client saves the server's host key to keep from having to repeat this phase.

Conversely, depending on its configuration, the server can sometimes verify that the client is who it claims to be. If the server has a list of hosts authorized to connect, it will encrypt a message using the client's public key (which it has in its host key database) to verify whether the client is capable of decrypting it with its private key (this is called a challenge).

Authentication

Once the secure connection is established between the client and the server, the client has to log on to the server to obtain an access right. There are several methods:

• the most well-known method is the traditional password. The client sends a login and a password to the server via the secure connection and the server checks whether the user in question has access to the machine and whether the password provided is valid.
• a lesser known but more flexible method is the use of public keys. If the client chooses key authentication, the server will create a challenge and give access to the client if the latter is able to decrypt the challenge with its private key

Last update on Thursday October 16, 2008 02:43:18 PM.This document entitled « Cryptography - Secure Shell (SSH protocol) » from Kioskea (en.kioskea.net) is made available under the Creative Commons license. You can copy, modify copies of this page, under the conditions stipulated by the licence, as this note appears clearly.