What is SSH and Its Components?

Can Secure Shell Really Makes Our Communication Secure?

Stefano Cacciaguerra

Department of Computer Science, University of Bologna

Mura A. Zamboni 7, 40127 Bologna, Italy

E-Mail: scacciag@cs.unibo.it

ABSTRACT

Making remote connections is an action so usual that nobody is conscious of her importance. A large percentage of computer users uses Internet Protocol (IP) to make a remote connection. The Internet Protocol is a communications protocol for local and global area network that provides efficient, cost-effective, and flexible connections, but it is not secure from bad eavesdroppers. The reason is that was designed twenty years ago in an Internet world of a few hundred closely controlled hosts. Now, the situation is very different: we have several millions of computers controlled by millions of individuals and organizations. The rapid growth of the Internet has interested businesses, military organizations, governments, and criminals. The relevant interest of business communications, scientific communications, and political communications on the Internet has also brought out usual negative elements. Criminals are looking for simple profits. Industrial espionage has moved online. Intelligence agencies are interested towards networked communications. Crackers exchange information and source code to make attacks. In this scenario, everybody searches for a way to protect his communications when it is making a remote connection. Secure SHell (SSH) is an architecture that allows secure network services over an insecure network, such as the Internet. The Secure Shell concept is originated on UNIX as a replacement for the insecure services as the rsh, rlogin, rcp, telnet and ftp. In this survey why is born SSH, how it works and which are its main problems are illustrated. This survey is useful to understand if we really need or not SSH. Finally, summary of this work is: “Can secure shell really make our communication secure?” In this paper, SSH is referenced to version 2 (ssh2), because SSH Communications Security considers the version 1 (ssh1) deprecated [CERT].

KEYWORDS: secure communication, SSH architecture, SSH protocol, cryptography,

and authentication method.

1. INTRODUCTION

The open architecture of the Internet Protocol (IP) implements a highly efficient, cost-effective, and flexible communications protocol for local and global communications [GS96]. It has been widely adopted, not only on the global Internet, but also on the internal networks of large corporations. The IP protocol suite, including TCP/IP, was designed to provide reliable and scalable communications over real-world networks. However, it was designed twenty years ago in an Internet world of a few hundred closely controlled hosts. Now, the Internet world is composed by several millions of computers, controlled by millions of individuals and organizations. The core network itself is administered by thousands of competing operators, and the network spans the whole globe, connected by fibers, satellites, radio-links, dial-up modems, and mobile phones.

The phenomenal growth of the Internet has interested of businesses, military organizations, governments, and criminals. Suddenly, the network is changing the way business is done. It is changing the nature of trade and distribution networks and the way individual people communicate with each other. The upsurge of business communications, scientific communications, and political communications on the Internet has also brought out the usual negative elements. Not only, criminals are looking for ways of getting a cut of the emerging business. Industrial espionage has moved online. Intelligence agencies are showing growing interest towards networked communications, and they often exchange information with domestic commercial interest and political groups. Crackers, exchanging information and source code, make attacks those ten years ago were thought to be within the reach of only the most powerful intelligence agencies. Sometime these attacks are made by teenagers using their home computer! It has turned out that the IP protocol, while very tolerant of random errors, is vulnerable to a number of malicious attacks. The most common types of attacks include:

• Eavesdropping a transmission (for example: looking for passwords, credit card numbers, or business secrets).

• Taking over a communication in such a way that the attacker can inspect and modify any data being transmitted between the communicating parties.

• IP spoofing or faking network addresses in order to fool access control mechanisms based on them or to redirect connections to a fake server.

A solution may be adopting the SSH (Secure SHell) protocol. The SSH protocol is designed to protect network communications against security hazards (see above). The diffusion of SSH is growing. In fact, in [LC01], using Cisco’s Netflow technology to monitor the type of traffic between SLAC and the Internet world, it is shown that one of three main components of the TCP traffic is SSH. The other two components are the well-known FTP (File Transfer Protocol) and WWW (World Wide Web). While the WWW traffic is relatively stable, the quantity of FTP and SSH traffic are highly variable. Therefore, what is SSH?

SSH is a protocol that allows to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another [Hun02]. This service [SSA02] provides strong authentication and secure communications over insecure channels. It is intended as a replacement for RLOGIN (Remote login), RSH (Remote SHell), and RCP (Remote Call Procedure). SSH protects the user from an illicit network “packet sniffing”, whereby un-encrypted passwords and text can be read by unscrupulous persons. SSH is most useful for logging into a UNIX computer [SSQ02] from a Windows [SWW02], [SWQ02] or Mac computer or from another UNIX computer, where the traditional RLOGIN and TELNET programs would not provide password and session encryption; the administrative personnel tend to use SSH exclusively in preference to TELNET or RLOGIN, except in cases where SSH is not available. This allows you to securely login to remote host computers, to execute commands safely in a remote computer, to securely copy remote files (with its SFTP service, Secure File Transfer Protocol), to forward X11 sessions (on UNIX), and to provide secure encrypted and authenticated communications between two non-trusted hosts. For example, BBCP (BaBar Copy Program), a represent of P2P (peer-to-peer) computing, uses SSH for authentication; providing a simple working model, if you can make SSH to a location, you can copy files to or from that location [HTL01]). Also arbitrary TCP/IP ports can be forwarded over the secure channel, enabling secure connection. It includes multiple cryptographic algorithms like 3DES, Blowfish, and AES. SSH serves a purpose that is similar to Kerberos, but it works consistently amongst different operating systems and is easier to administer (no ticket- server is required, sysadmin privileges are not required to set it up) [SSA02]. SSH Secure Shell with its array of unmatched security features is an essential tool for today’s network environment. It is a powerful sentinel against the numerous

security hazards that nowadays threaten network communications. In particular it is possible to install the Secure Shell client functionality, for Handhelds, in a compact package suitable for small memory and disk space, and low connection speed of the wireless information devices [SHU01]. SSH for Handhelds is currently available for the Symbian 6.0 operating system as provided by the Nokia 92x0 Communicator devices.

The reminder of this paper is organized as follows. In the second section it’s described an overview of the SSH Architecture, while in the third one it’s spoken about SSH Transport Layer Protocol, the SSH User Authentication protocol and SSH connection protocol. In the fourth one it’s shown same troubles and trouble shootings, and, finally, section 5 concludes the paper. This introduction section has given an overview of some of the security risks facing the Internet user and introduces the SSH protocol to combat these risks. It’s important to specify that SSH, in this paper, is referenced to version 2 (ssh2), because SSH Communications Security considers the SSH protocol version 1 (ssh1) deprecated and does not recommend to use it [CERT]. However the SSH software includes support for compatibility with version 1.x.

2. ARCHITECTURE

SSH is a protocol that allows secure remote login and other secure network services over an insecure network. The main components of SSH architecture [Ylö96],[RYK02a] are three:

• the Transport Layer Protocol • the User Authentication Protocol • the Connection Protocol

The first component provides server authentication, confidentiality, integrity and optionally compression. The transport layer will typically be run over the top of any reliable data stream, in particular over TCP/IP connection. The second one, running over SSH transport layer protocol, authenticates the client-side user to the server. Finally, the third one, running over user authentication protocol, multiplexes the encrypted tunnel into several logical channels (See figure 1).

TCP/IP

SSH Transport Layer Protocol

SSH User Authentication Protocol

SSH Connection Protocol

Figure 1: SSH protocol stack

The SSH communication works on top of the packet-level protocol, and proceeds in the following phases:

2. The server sends its public host key and another public key (“server key”) that changes every hour. The client compares the received host key against its known host keys. 3. The client generates a 256 bit random number [ECS94] using a cryptographically strong

random number generator, and chooses an encryption algorithm from those supported by the server (see table 2). The client encrypts the random number (session key) with a public key algorithm, using both the host key and the server key, and sends the encrypted key to the server.

4. The server decrypts the public key encryptions and recovers the session key. Both parties start using the session key (until this point, all traffic has been unencrypted on the packet level). The server sends an encrypted confirmation to the client. Receipt of the confirmation tells the client that the server was able to decrypt the key, and thus holds the proper private keys.

At this point, the server machine has been authenticated, and transport level encryption and integrity protection are in use.

5. The user is authenticated to the server. The client sends requests to the server. The first request always declares the user name to log in as. The server responds to each request with either “success” (no further authentication is needed) or “failure” (further authentication is required).

6. After the user authentication phase, the client sends requests that prepare for the actual session. Such requests include allocation of a tty, X11 forwarding, TCP/IP forwarding, etc. After all other requests, the client sends a request to start the shell or to execute a command. This message causes both sides to enter the interactive session.

7. During the interactive session, both sides are allowed to send packets asynchronously. The packets may contain data, open requests for X11 connections, forwarded TCP/IP ports, or the agent, etc. Finally at some point the client usually sends an EOF message. When the user's shell or command exits, the server sends its exit status to the client, and the client acknowledges the message and closes the connection

After the description of how SSH communication works, general architectural features are explained. The SSH protocol make some assumptions: all encryption, integrity, and public key algorithms used are well-known. All algorithms are used with cryptographically key sizes that are assumed to protect against cryptanalytic attacks for next years. All algorithms are negotiated. If some algorithm is broken, it is possible to use some other algorithm without modifying the protocol on the below level. To avoid USA export regulations about the encryption software, all used algorithms are developed in Europe, so SSH software can be used in any country that allows encryption, including the USA. Important aspects of this architecture are the management of host keys and policy issues.

2.1 Host Keys

In this architecture each server host should have a host key; in particular it may have multiple host keys for multiple different algorithms. Each server host should have at least one key for each standard public key algorithm [FIP94]. During key exchange phase the client establishes the

server authenticity, checking its host key. About this point the client must know to priori the server’s public host key. It’s possible to achieve this point in two different ways:

• The client stores in a local database each host name and its corresponding public host key. This method requires no centrally administered infrastructure, and no super-partes coordination. The drawback is that the database of name-to-key associations may be cumbersome to maintain.

• The host name-to-key association is certified by some super-partes coordinator. The client can check all host keys certified by a trusted certification authority whose it knows the root key. In this case the client database maintains only a single key (the CA root key), so the drawback is that each host key must be certified by a central authority before every authorization.

2.2 Policy Issues

SSH is born to make secure an insecure network with variegated services controlled by millions of individuals and organizations. Everyone wants to use their preferred encryption, integrity, key exchange, compression, and public key algorithms and formats, so it should be possible the full negotiation. Furthermore these algorithms can be chosen different for each direction. To reach this aim, it should be possible specified the following policy issues in the configuration of each mechanisms. To have Encryption, integrity, and compression algorithms, separately for each direction, the policy specifies the preferred algorithm (e.g. the position behind the algorithm list for each category). During the host authentication the policy specifies public key algorithms and key exchange method. Furthermore it’s possible that the server’s policy requires multiple authentications for some or all users. Finally the policy specifies the permitted user’s operations using the connection protocol. This is relegated to security level of requested service.

3. PROTOCOLS

In this section, the details of SSH Transport Layer Protocol, the SSH User Authentication protocol and SSH connection protocol are explained

3.1 Transport Layer Protocol

The SSH transport layer [RYK02b] is a secure low level transport protocol, that works normally over TCP/IP listening for connections on port 22. It supplies strong encryption, cryptographic host authentication, and integrity protection (see figure 6). Authentication is host-based, in fact it’s the higher level protocol to provide user authentication. The SSH transport layer permits negotiation of key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm. Furthermore it minimizes the number of round-trips that will be needed for full key exchange, server authentication, service request, and acceptance notification of service request. The number of round-trips is normally two, but it becomes three in the worst case [RYK02b]. The subphases of this protocol are three and the sequence is: compression, mac and encription. During the exchanging period each packet has the format of figure 2. The payload contains the exchanging datas, which may be compressed. The random padding is necessary to make become the length of the string (packet_length || padding_length || payload || padding) divisible by the cipher block size or 8.

uint32 packet_length byte padding_length byte[n1] payload

byte[n2] Random padding; byte[m] mac

Where:

n1 = packet_length - padding_length – 1

n2 = padding_length

m = mac_length

Figure 2: packet format in the exchanging phase

Compression algorithm may be different for each direction of communication. To guarantee data integrity, each packet includes a MAC. The MAC phase is not included at the first time when its length is zero. Only after the key exchange, MAC will be in effect. The MAC is calculated from a shared secret, packet sequence number and part of packet (the length fields, payload and padding):

MAC = mac(key, sequence_number || unencrypted_packet)

The sequence number range begins from zero and ends to (232-1); the packet sequence number is not sent inside the exchanged packets. MAC algorithm (see table 1) may be different for each direction of communication.

NAME EXPLANATION

hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key length =20)

hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest length = 12, key length = 20) hmac-md5 OPTIONAL HMAC-MD5 (digest length = key length = 16)

hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest length = 12, key length = 16) none OPTIONAL no MAC; NOT RECOMMENDED

Table 1: SSH classification of MAC algorithms. Finally, the string

(packet_length || padding_length || payload || padding)

is encrypted; it is important note that also the packet length field is encrypted. This trick is adopted to hide the dimension of payload, because a part of exchanged packet is random padding, the other one is the exchanged datas. The minimum size of a packet is 16 or the cipher block size bytes plus MAC length. The maximum size is respectively of 32768 bytes for uncompressed payload length and of 35000 bytes for total packet. It’s specified the dimension of uncompressed payload, because this field, and only it, may be compressed using an appropriate algorithm. In the encryption phase the packet length, padding length, payload and padding fields of each packet are encrypted with negotiated algorithm and key. Encryption algorithm (see table 2) may be different for each direction of communication, in particular all encrypted packets sent in one direction is considered as single data stream. It’s recommended to not use key length less than 128 bits.

NAME EXPLANATION

3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc RECOMMENDED Blowfish in CBC mode

twofish256-cbc OPTIONAL Twofish in CBC mode, with 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" twofish192-cbc OPTIONAL Twofish with 192-bit key

twofish128-cbc RECOMMENDED Twofish with 128-bit key

aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, with 256-bit key aes192-cbc OPTIONAL AES with 192-bit key

aes128-cbc RECOMMENDED AES with 128-bit key

serpent256-cbc OPTIONAL Serpent in CBC mode, with 256-bit key serpent192-cbc OPTIONAL Serpent with 192-bit key

serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode cast128-cbc OPTIONAL CAST-128 in CBC mode

none OPTIONAL no encryption; NOT RECOMMENDED

Table 2: SSH classification of cipher algorithms. Key Exchange Methods

Above it is spoken about the subphases of exchange period, here it is illustrated the key exchange methods at the beginning of that period. During the first connection, the key exchange method indicates the generation of keys for encryption and authentication, and how the server authentication is done. The only required key exchange method is diffie-hellman. This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption); see table 3.

NAME EXPLANATION

ssh-dss REQUIRED Simple DSS

ssh-rsa RECOMMENDED Simple RSA x509v3-sign-rsa OPTIONAL X.509 certificates(RSA key) x509v3-sign-rsa OPTIONAL X.509 certificates(DSS key) spki-sign-rsa OPTIONAL SPKI certificates(RSA key) spki-sign-dss OPTIONAL SPKI certificates (DSS key) pgp-sign-rsa OPTIONAL OpenPGP certificates(RSA key) pgp-sign-dss OPTIONAL OpenPGP certificates(DSS key)

Table 3: public key and/or certificate formats

At the beginning of key exchange each side sends a list of supported algorithms (see figure 3). Each side has an own algorithm in each category and tries to guess that one of the other side. The guess may be wrong if kex algorithm and/or the host key algorithm are different for server and client or if any of the listed algorithms cannot be agreed upon. Otherwise, the guess is right and the sent packet are handled as the first key exchange packet. Before beginning the communication, the client waits for response to its service request message.

byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension)

Figure 3: Key exchange packet

Encryption and authentication keys are derived, after the key exchange by an exchange hash H and a shared secret K. From the first key exchange, the hash H is used additionally as the session identifier, in particular as authentication method. In fact this is the proof of possession of the right private key. The exchange hash H lives for the session duration, and it will not be changed. Each key exchange method specifies a hash function that is used in the key exchange to compute encryption keys:

• Initial IV client to server: HASH(K || H || “A” || session_id) • Initial IV server to client: HASH(K || H || “B” || session_id) • Encryption key client to server: HASH(K || H || “C” || session_id) • Encryption key server to client: HASH(K || H || “D” || session_id) • Integrity key client to server: HASH(K || H || “E” || session_id) • Integrity key server to client: HASH(K || H || “F” || session_id)

Where K is a known value and “A” as byte and session_id as raw data. Key data is taken from the beginning of the hash output, at least 128 bits (16 bytes). Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message must use the new keys and algorithms.

The shared secret K is provided by the Diffie-Hellman key exchange [Sta98]. Each side is not able to determine alone a shared secret. To supply host authentication, the key exchange is combined with a signature with the host key. In the following description: p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup; V_S is server’s version string; V_C is client’s version string; K_S is server’s public host key; I_C is client’s KEXINIT message and I_S server’s KEXINIT message which have been exchanged before this part begins.

1. Client generates a random number x (1 < x < q) and computes e = gx mod p. C sends “e” to server (figure 4).

2. Server generates a random number y (0 < y < q) and computes f = gy mod p. Server receives “e”. It computes K = ey mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (table 4), and signature s on H with its private host key. Server sends “K_S || f || s” to C (figure 5). The signing operation may involve a second hashing operation.

3. Client verifies that K_S really is the host key for Server (e.g. using certificates or a local database). Client is also allowed to accept the key without verification (insecure). Client then computes K = fx mod p, H = hash(V_C || V_S || I_C || I_S ||K_S || e || f || K) (table 4), and verifies the signature s on H.

Either side must not send or accept “e” or “f” values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails.

byte SSH_MSG_KEXDH_INIT mpint e

Figure 4: packet from client to server

byte SSH_MSG_KEXDH_REPLY

string server public host key and certificates (K_S) mpint f

string signature of H

Figure 5: packet from server to client

TYPE NAME EXPLANATION

string V_C the client's version string (CR and NL excluded) string V_S the server's version string (CR and NL excluded) string I_C the payload of the client's SSH_MSG_KEXINIT string I_S the payload of the server's SSH_MSG_KEXINIT string K_S the host key

mpint e exchange value sent by the client mpint f exchange value sent by the server mpint K the shared secret

Table 4: hash components

It’s possible re-exchange keys and above all it’s recommended when the communication transmitted more than a gigabyte of data or it is during more than an hour. However, the re-exchange keys operation requires computational resources, so it should not be performed too often. This operation is equal to the initial key exchange: it’s possible to negotiate some or all of the algorithms, all keys and initialization vectors are recomputed after the exchange and compression and encryption contexts are reset. The only thing that remains unchanged is the session identifier.

After key exchange, the client requests a service, passing through SSH user authentication protocol. The service is identified by a name. When service end, user may want to terminate the connection. After this message the client and server must not send or receive any data.

3.2 User Authentication Protocol

The SSH authentication protocol is a general-purpose user authentication protocol [RYK02c], running over the SSH transport layer protocol. At the beginning this protocol receives the session identifier from the lower-level protocol to identify session and to prove ownership of a private key. The SSH authentication protocol expects that SSH transport layer protocol provides integrity and confidentiality protection. The server begins the authentication asking to the client which

authentication methods can be used to continue the exchange at any given time. The client can choose the methods listed by the server in any order. The server has a timeout for authentication and a maximum number of failed authentication attempts. An user authentication protocol session provides for an authentication request and response. Finally, it is spoken about the user authentication method based on public key. After the user authentication, it should be verified password (see figure 6).

Figure 6: settings to configure SSH client Authentication Requests

In figure 7 it’s possible to see the authentication request message format. The user and service name appear in every new authentication attempt. These may change; therefore the server checks them in every message. If there are some changes the server must update authentication states. If it is unable to make it, it disconnects the user for that service. In particular the user name specifies the user identity and the service name that he wants to start after authentication. If the user name does not exist, the server may send a list of acceptable authentication methods, but in any case the authentication request is rejected avoiding to disclose informations on existing logins. If the requested service is not available or does not exist, the server may disconnect the user for that service, sending it an apposite disconnect message. The last defined field is the name of authentication method; the remaining ones depend on the authentication method. In particular an authentication request may result in a further exchange of messages.

byte SSH_MSG_USERAUTH_REQUEST string user name

string service name string method name

The rest of the packet is method-specific.

Authentication Responses

In figure 8 it’s possible to see the rejection of authentication request message. In “Authentications that can continue” there is a list of authentication method names with which it’s possible to continue the authentication dialog.

byte SSH_MSG_USERAUTH_FAILURE string authentications that can continue boolean partial success

Figure 8: rejection of authentication request message

When the server accepts authentication and only when the authentication is complete, it responds with the message of figure 9.

byte SSH_MSG_USERAUTH_SUCCESS

Figure 9: acceptance of authentication request message

The client is not obligated to wait for responses from previous requests, so it may send several authentication requests. Otherwise the server must process each request before processing the next request. It is not possible to send a second request without waiting for a response from the server. In fact if the first request will result in further exchange of messages, that one will be aborted by a second request. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. SSH_MSG_USERAUTH_SUCCESS is sent only once any further authentication requests received after that is silently ignored, passing directly that request to the service being run on top of this protocol. It’s possible for a client to use the “none” authentication method. If no authentication is needed for user, server returns SSH_MSG_USERAUTH_SUCCESS. Otherwise, server returns SSH_MSG_USERAUTH_FAILURE.

Authentication Method

In the authentication at the lower-level it’s been created a secure channel between the client and the server, but different user may run this operation from the same client to the same server; so it’s required, as user authentication method. The main user authentication methods are two: a public key or a password authentication (see figure 6). In the first method the possession of a private key serves as authentication. The user sends a signature created with its private key. The server checks that the public key and the signature for the user are valid. If it’s valid, the authentication request is accepted; otherwise it is rejected. In figure 10 it’s possible to see the message format for querying whether authentication using the key would be acceptable.

byte SSH_MSG_USERAUTH_REQUEST string user name

string Service string "publickey" boolean FALSE

string public key algorithm name string public key blob

Figure 10: message format for querying whether authentication using the key would be acceptable

Public key algorithms are defined in the transport layer specification (table 3); in particular the list is not constrained by what was negotiated during key exchange. The public key blob may

contain certificates. The server responds to this message with either SSH_MSG_USERAUTH_FAILURE or with the SSH_MSG_USERAUTH_PK_OK (figure 11).

byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request

Figure 11: acceptance of authentication message

To perform actual authentication, the client may send the signature, generated using its private key, directly without first verifying whether the key is acceptable (figure 12).

byte SSH_MSG_USERAUTH_REQUEST string user name

string service string "publickey" boolean TRUE

string public key algorithm name

string public key to be used for authentication string signature

Figure 12: message with signature

Signature is created by the corresponding private key over the data of figure 13.

string session identifier

byte SSH_MSG_USERAUTH_REQUEST string user name

string service string "publickey" boolean TRUE

string public key algorithm name

string public key to be used for authentication

Figure 13: data used in this order by signature

When the server receives this message, it checks whether the supplied key is acceptable for authentication, and if so, it checks whether the signature is correct. If both checks succeed, this method is successful. (Note that the server may require additional authentications.) The server responds with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed). In the second method, the possession of a password serves as authentication (see figure 14). The server interprets the password and validates it against the password database; it may request user to change password. It’s important to remember that if a cleartext password is transmitted in the packet, however this one is encrypted by SSH transport layer.

byte SSH_MSG_USERAUTH_REQUEST string user name

string service string "password" boolean FALSE string plaintext password

If the lower-level does not provide confidentiality, password authentication is disabled. Beside if the lower-level does not provide confidentiality or integrity password change is disabled. In general, the server responds to the password authentication packet with success or failure. In a failure response if the user password has expired server can reply to user with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ (figure 16). In any case server must prevent from logging users with expired password; then the client may continue with another authentication method, or request a new user password (figure 17).

byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt

string language tag

Figure 16: Change request password

byte SSH_MSG_USERAUTH_REQUEST string user name

string service string "password" boolean TRUE

string plaintext old password string plaintext new password

Figure 17: retry password authentication Finally the server must reply to request message with one of this message:

• SSH_MSG_USERAUTH_SUCCESS: the password has been changed, and authentication has been successfully completed.

• SSH_MSG_USERAUTH_FAILURE with partial success: the password has been changed, but more authentications are needed.

• SSH_MSG_USERAUTH_FAILURE without partial success: the password has not been changed. Either password changing was not supported, or the old password was bad. • SSH_MSG_USERAUTH_CHANGEREQ: the password was not changed because the

new password was not acceptable.

3.3 Connection Protocol

Finally on the top of the SSH stack we find the SSH Connection Protocol [RYK02d] that provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. The requests may be several, different and may use independent channels. All such requests use the format of figure 18 and the server answers success or failure with that one of figure 19.

Byte SSH_MSG_GLOBAL_REQUEST String request name

Boolean want reply ... request-specific data follows

Byte SSH_MSG_REQUEST_SUCCESS ... request-specific data

Byte SSH_MSG_REQUEST_FAILURE ... request-specific data

figure 19: above) success response format, below) failure response format

In the channel mechanism all terminal sessions and forwarded connections are channels. Each side may open a channel. Multiple channels are multiplexed into a single connection. Channels are identified by numbers at each end (these numbers may be different on each side). Channels are flow-controlled; so no data may be sent to a channel until a message is received to indicate that window space is available. To open a new channel, each side allocates a local number and sends the message of figure 20 to the other side including the local channel number and initial window size.

Byte SSH_MSG_CHANNEL_OPEN String channel type

Uint32 sender channel Uint32 initial window size Uint32 maximum packet size

... channel type specific data follows

Figure 20: message to open a channel

In particular the fields of this message are defined following. Sender channel is a local sender identifier for the channel. Initial window size specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. Maximum packet size specifies the maximum size of an individual data packet that can be sent to the sender. On other side the remote machine decides whether it can open the channel, and it may respond with its open confirmation message (see figure 21).

Byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION Uint32 recipient channel

Uint32 sender channel Uint32 initial window size Uint32 maximum packet size

... channel type specific data follows

Figure 21: message to confirm the opening of the channel

In particular recipient channel is the channel number given in the original open request. Whether it can not open the channel, because does not support the specified channel type, it responds with SSH_MSG_CHANNEL_OPEN_FAILURE (see figure 22). If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support the specified channel type, it simply responds with SSH_MSG_CHANNEL_OPEN_FAILURE. After the opening of the channel some data is transmitted on this one. During the communication on channel, the data transfer is

controlled by the window size that specifies how many bytes the other party can send before it must wait for the window to be adjusted.

Byte SSH_MSG_CHANNEL_OPEN_FAILURE Uint32 recipient channel

Uint32 reason code String additional textual information String language tag

Figure 22: message to fail the opening of the channel

The maximum amount of allowed data is the current window size. The amount of data sent decrements the window size. Each side may ignore all extra data sent after the allowed window is empty. When a side will no send more data to a channel, it send MSG_CHANNEL_EOF (see figure 23), but no explicit response is sent to this message. It is important to note that the channel remains open after MSG_CHANNEL_EOF, and more data may be transferred in each direction.

Byte SSH_MSG_CHANNEL_EOF Uint32 recipient channel

Figure 23: message to suspend a communication on a channel

Finally, when each side wants to terminate the channel, one sends a SSH_MSG_CHANNEL_CLOSE message (see figure 24) and waits to receive back the same message. The channel is closed for each side when it has both sent and received SSH_MSG_CHANNEL_CLOSE

Byte SSH_MSG_CHANNEL_CLOSE Uint32 recipient channel

Figure 24: message to close the channel

Many channel types have extensions that are specific to that particular channel type (for example requesting a pseudo terminal for an interactive session). All channel-specific requests use the following format of figure 25.

Byte SSH_MSG_CHANNEL_REQUEST Uint32 recipient channel

String Request type Boolean want reply

… type-specific data

Figure 25: channel-specific request format

If want reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. Request types are local to each channel type. To complete this section, it is defined a session as a remote execution of a program. The program may be an X11 Forwarding, a TCP/IP Port Forwarding, a Shell, a command, an

application, a system command, or some built-in subsystem. Multiple sessions can be active simultaneously.

4. TROUBLES and TROUBLESHOOTING

After the explanation of the SSH architecture, now some important troubles deriving from using of SSH, are analyzed. Some troubles may be general, some others may be specific of a protocol of SSH stack.

4.1 General Problem

The general problems are three. The first is an historical problem, the second is about increasing in the communication latency and the third is about timing analysis of keystrokes and timing attacks on SSH.

Historical Problem

As already said in the introduction, it’s important to specify that SSH, in this paper, is referenced to version 2 (ssh2), because SSH Communications Security considers the SSH protocol version 1 (ssh1) deprecated and does not recommend to use it [CERT]. For sake of completeness it is reported a list of motivation:

• Passwords sent over SSH1 using the RC4 (Ron’s code 4) cipher can be cracked if NULL passwords are disallowed on the server.

• SSH1 connections using RC4 and password authentication can be replayed.

• Because the CRC (Cyclic Redundancy Check) checksum used with the RC4 cipher can be modified, packets can be modified arbitrarily.

• SSH1 allows client authentication to be forwarded if client accepts unknown host keys. • SSH1 allows client authentication to be forwarded if encryption is disabled.

The solutions to the list of motivation problems provide: to not use the RC4 cipher for SSH1 connections, to disable RC4 and password authentication, to not attempt an SSH1 connection if encryption is disabled and finally to upgrade to SSH2. SSH2 has not these problems. For higher level of details, you can read [CERT] and related literature.

Communication Latency Problem

It is important to remember that SSH is able to make secure network services over an insecure network, but it increases in the communication latency. The increase of packet size due to new headers, padding, and MAC, and the increase of the number of exchanged network messages can decrease the performance of network communication. The minimum packet size due to SSH protocol may be in the order of 28 bytes, that should be negligible for large packets, but very significant for small packets, like telnet-type sessions. This problem has not particular solution. Timing Analysis of Keystrokes Problem

The third general problem is about timing analysis of keystrokes and timing attacks on SSH [SWT01]. A research into applying traffic-analysis techniques to interactive SSH connections is used in order to infer information about the encrypted connection contents. This research concludes that the keystroke timing data observable from today’s SSH implementations reveals a dangerously significant amount of information about user terminal sessions. These informations are enough to locate typed passwords in the session data stream and reduce the computational work involved in guessing those passwords by a factor of 50. The research revolves around the

notion of traffic analysis, and while it uses SSH as a concrete example, the techniques involved are not specific to SSH, but rather apply to most interactive remote-terminal protocols as they are implemented today. The principle of traffic analysis is that there is a lot of useful information to be gleaned from the amount, timing, and direction of network traffic, even if you can’t actually read the traffic content itself. Suppose someone is monitoring the network port leading to a system administrator’s office. Perhaps someone can’t read or alter SSH connections, but it can see:

• when those connections are made and torn down or when it arrives at work and leaves for the evening.

• the addresses of the connected machines, telling the attacker which hosts it is responsible for (and which ones it is not looking at).

• the amount, rate, and timing of traffic going over the SSH sessions (separately in each direction), giving me some information about what it is doing. (For example, it is possible to distinguish between terminal and file-transfer sessions.)

• when all the terminal sessions go quiet, suggesting it may be out to lunch and now it is a good time to hack its workstation (or break into its office).

These sorts of information leaks are very difficult to prevent. If you control all the physical components in your network and you can ensure that they all use link-level encryption and appropriately random idle-traffic generation, then that would be a start towards preventing traffic analysis. But this scenario is understandable for very specific high-security installations; most of us have neither the opportunity nor the benefit of such designs. Considering the expense (or practical impossibility) of such countermeasures, traffic analysis is usually considered an unavoidable risk. When accepting this risk, however, we generally assume that the danger is wholly indirect: an observer may be able to guess some useful ancillary information from traffic patterns, but the actual data is safe as long as we’re using a good protocol, such as SSH. The disturbing conclusion of this recent research is that this is not so; using sophisticated mathematical techniques it is possible to gather significant amounts of information about the contents of an SSH terminal session, by taking advantage of its interactive nature. The delivery requirements for interactive traffic are more different than those for bulk data transfer. When transmitting a file, TCP data can be batched up and sent in large IP datagrams for efficiency. But when you type a character in a terminal session, you expect to see it echoed immediately. So programs like Telnet and SSH send terminal data as soon as it becomes available, which means that the TCP connections for these programs transmit many short IP packets containing individual keystrokes and their echoes. This real-time reflection of the user’s typing behavior in the network stream is the basis of the research’s attack. Typical transmission latency is negligible when compared with the inter-keystroke delays revealed by timing the arrival of single-keystroke TCP packets. Therefore, measuring packet-arrival times gives an accurate picture of the user’s actual gestures at the keyboard. The research supports that keystroke timing leak reveals significant information about the keys pressed and informations can be guessed at keystroke sequences. To summarize very broadly, the authors use a statistical technique called a Hidden Markov Model (HMM) to capture a user’s keyboard habits, given data gathered from observing typing patterns and used to “train” the model. Then they use a prediction algorithm to guess at key sequences, given only the inter-keystroke timings together with the previously constructed model. The researchers tested their technique experimentally, using training data from real human subjects. The results suggest a 50-fold reduction in the work required for an offline dictionary attack. In the long term, if this sort of attack proves to be a serious problem, it will be a good idea to develop better protocols and deploy different networking technologies to address these attacks. Traffic analysis is a hard problem with no immediate, easy answers. Some approaches, all of which need further research and testing, may be:

• Introduce random jitter into keystroke packets as they are sent. This obvious approach has problems, though, because if the jitter is in fact random, an observer may be able to filter it out over repeated timings of the same password.

• Send a constant stream of packets even when idle, thus masking the real traffic among the fake. The dummy packet timings would have to be carefully crafted to be indistinguishable from the real ones, and the rate chosen is a tradeoff between security and both user-visible latency and network overhead. These solutions could increase the questions about the second general problem.

The issues rose in the research of Song, Wagner, and Tian are not a reason for panic. The attack presented is sophisticated and it has not yet demonstrated how well this research will translate into general real-world attacks. However, the issues are serious and real, and hopefully the paper will heighten awareness of traffic analysis as a threat and spur more research into practical countermeasures.

4.2 Problem of SSH Specific Protocols

Now it is spoken about specific problems of designing a part of SSH stack. Some security considerations, about problems in the architecture [RYK02a], concern:

• generating random numbers

• displaying error or debug messages to the user • not using MAC or encryption

Special care should be taken to ensure that all of the random numbers are of good quality. The random numbers should be produced with safe mechanisms as discussed in [ECS94]. When displaying text, such as error or debug messages to the user, the client software replaces any control characters (except tab, carriage return and newline) with safe sequences to avoid attacks by sending terminal control characters. Not using MAC or encryption must be avoided! In fact the user authentication protocol will be subject to man-in-the-middle attacks if the encryption is disabled and again, the SSH protocol does not protect against message alteration if no MAC is used. As already described in the second section the SSH architecture is divided in three protocols: transport, user authentication and connection. Now some considerations about problems in these protocols are shown.

Problems in the Transport Protocol

Some security considerations, about problems in the transport [RYK02b], concern:

• using this protocol without a reliable association between the server host key and the server host name

• ignoring the covert channels problem • using CBC mode (Cipher Block Chaining)

It is important remember that this protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. Sometimes this protocol will may be used without a reliable association between the server host key and the server host name. This is an insecure use, but may be necessary in non-security critical environments, and still provides protection against passive attacks. However, designers of the upper protocols should keep in mind this possibility. The SSH transport protocol is designed

to be used over a reliable connection, so if transmission errors or message manipulation occur, the connection will be closed. The connection can be established again if this occurs. Denial of service attacks of this type, named “wire cutter”, are almost impossible to avoid. This protocol ignores the problem to eliminate covert channels. In fact several places in this protocol can be used to pass covert information. The recipient has no reliable way to verify whether such information is being sent. In the section about this protocol it is said that it is strongly recommended to rekey at least once per gigabyte of data. This action reduces the chance that a “birthday paradox” collision will appear. In fact all ciphers specified in this document are used in CBC mode (Cipher Block Chaining). The problem is that some time CBC modes will reveal information about the plaintext if two ciphertext blocks encrypted under the same key are equal. Besides recent research shows a new possible attack on CBC mode. This attack allows a chosen plaintext attacker aware of the IV for a forthcoming message to have some chance to artificially induce a system into generating ciphertext collisions. This allows the attackers to guess at likely prior plaintexts. In particular, any protocol which uses CBC in a way which allows advance knowledge of a message’s IV might be vulnerable to this attack. However the last SSH protocol versions are very resistant to this attack. In fact attacker would need tens or hundreds of millions of opportunities to inject chosen plaintexts to be encrypted with a known IV to confirm guesses on the value of a few unknown plaintexts. This attack involves less work than a brute-force attack on the underlying cipher. In fact it is likely to be more difficult than attacks on other parts of this system. So it is unlikely to be an immediate risk to real-world systems. Again, if is used the trick that rekeying must occur once an hour, an attacker also has a limited amount of time to complete any particular attack. However an evolution of these problematici will may occur in future. Problems in the User Authentication Protocol

Some security considerations, about problems in the user authentication [RYK02c], concern: • not providing encryption

• not providing MAC protection • providing debug messages

The main aim of this protocol is to perform client user authentication. This protocol should work over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communication, and computed a unique session identifier for this session. So the transport layer provides forward secrecy for password authentication and other methods that rely on secret data. Much of choices at the level depend from lower level. In fact if the transport layer does not provide encryption, authentication methods that rely on secret data should be disabled and if it does not provide MAC protection, requests changing password should be disabled. This last measure is useful to avoid an attacker from modifying the ciphertext without being noticed. At this level several authentication methods with different security characteristics are allowed. The server’s local policy decides which methods or combinations of methods; it will be used in each user authentication. Debug messages may be a problem because they may reveal amounts of information about the host if they are not properly designed. During user authentication phase, if high security is required debug messages can be disabled.

Problems in the Connection Protocol

Some security considerations, about problems in the connection [RYK02d], concern: • permitting the server to run commands on the client

• X11 forwarding • Port forwarding

This protocol should work on top of a secure, authenticated transport. It is assumed that user authentication and protection against network-level attacks should be provided by the underlying protocols. The main aim of this protocol is to execute commands on remote machines. The protocol also permits server to run commands on client. This can be dangerous and can promote an attacker from coming from the server machine to the client machine. In particular X11 forwarding provides greater security improvements than over normal cookie-based X11 forwarding. The cookie is encrypted and integrity-protected and no useful authentication data will remain on the server machine after the connection has been closed. Anyway nobody can prevent to use a forwarded X11 connection to get access to the local X server across security perimeters. In the same way port forwardings can potentially allow an attacker to cross security perimeters such as firewalls. To avoid this problem designers should allow policy control over what can be forwarded and administrators should be able to deny forwardings where can be dangerous [ZCC00]. In fact until this protocol runs inside an encrypted tunnel, firewalls will not be able to examine the traffic. It is important that designers disable all the potentially dangerous features if the host key has changed.

5. CONCLUSION

In the most famous computer network, the large diffusion of political and economical interests has made be born the most common types of attacks to communication. Eavesdroppers look for passwords, credit card numbers, or business secrets. Hackers take over a communication to inspect and modify any data being transmitted between the communicating parties. Crackers fake network addresses in order to fool access control mechanisms based on them or to redirect connections to a fake server. The main aim of this paper is to response to the question of the title:“ In a situation like this, can secure shell really make our communication secure ?” Secure Shell is certainly an architecture that tries to allow secure network services over an insecure network and is certainly an evolution of the insecure services as the rsh, rlogin, rcp, telnet and ftp. Nevertheless the Secure Shell is not able to give assurance that its user is immune to all attacks. In fact it is not able to avoid that an attacker knows: when connections are made and torn down, or when user arrives at work and leaves or the addresses of the connected machines, or the amount, rate, and timing of traffic go over the SSH sessions or when all the terminal sessions go quiet. Besides, the paper [SWT01] demonstrated that is possible a 50-times reduction in the work required for an offline dictionary attack. Again this bug may have a solution but this one compromises the performance of the network. So SSH it could not be an universal solution and in particular for applications that requires performance constrains. Besides, if someone should send a very secret message it is better to use other technique more adequate like information hiding [CF02]. In particular the steganography says that is better hiding messages rather than enciphering them, because it arouses less suspicion. However at the actual state of technology SSH is a good solution for the daily remote connections and an interesting substitute of services as the rsh, rlogin, rcp, telnet and ftp. Perhaps connections to not reliable computers and through not reliable network should be avoided. To make SSH more secure, designers should allow policy control over what can be forwarded and administrators should be able to deny forwardings where can be dangerous [ZCC00].

BIBLIOGRAFY

[CERT] CERT Coordination Center, “SSH statement regarding the vulnerability of SSH1 protocol”, http://www.ssh.com/products/ssh/cert/.

[CF02] S. Cacciaguerra & S. Ferretti, “Data Hiding: Steganography and Copyright Marking”, http://www.cs.unibo.it/~scacciag, Settember 2002.

[ECS94] D. Eastlake, D., Crocker, S. and J. Schiller, “Randomness Recommendations for Security”,

Request For Comments,RFC 1750, December 1994.

[FIP94] Federal Information Processing Standards Publication, “FIPS PUB 186, Digital Signature Standard”, May 1994.

[GS96] S. Garfinkel & G. Spafford, “Practical UNIX & Internet Security”, 2nd Edition, O'Reilly, 1996.

[HTL01] A. Hanushevsky, A. Tunov & L. Cottrell, “Peer-to-Peer Computing for Secure High Performance Data Copying”, COMPUTING IN HIGH ENERGY AND NUCLEAR PHYSICS, Hosted By IHEP, Beijing, China September 3 - 7, 2001.

[Hun02] C. Hunt, “TCP/IP Network Administration”, 3rd Edition, O'Reilly, April 2002.

[Ylö96] Tatu Ylönen, “SSH – Secure Login Connections over the Internet”, In 6th USENIX Security Symposium, San Jose, California, July 1996.

[LC01] C. Logg & L. Cottrell, “Passive Performance Monitoring and Tracking Characteristics on the SLAC Internet Border”, COMPUTING IN HIGH ENERGY AND NUCLEAR PHYSICS, Hosted By IHEP, Beijing, China September 3 - 7, 2001.

[RYK02a] T. Rinne, T. Ylonen, T. Kivinen, M. Saarinen & S. Lehtinen, “SSH Protocol Architecture”, draft-ietf-architecture-12.txt, Internet Draft, Internet Engineering Task Force, February 2002. Work in progress.

[RYK02b] T. Rinne, T. Ylonen, T. Kivinen, M. Saarinen & S. Lehtinen, “SSH Transport Layer Protocol”, draft-ietf-transport-14.txt, Internet Draft, Internet Engineering Task Force, March 2002. Work in progress.

[RYK02c] T. Rinne, T. Ylonen, T. Kivinen, M. Saarinen & S. Lehtinen, “SSH Authentication Protocol”, draft-ietf-userauth-15.txt, Internet Draft, Internet Engineering Task Force, March 2002. Work in progress.

[RYK02d] T. Rinne, T. Ylonen, T. Kivinen, M. Saarinen & S. Lehtinen, “SSH Connection Protocol”, draft-ietf-connect-15.txt, Internet Draft, Internet Engineering Task Force, February 2002. Work in progress.

[SHU01] “SSH Secure Shell for Handhelds Version 1.01UserManual”, http://www.ssh.com, SSH Communications Security Corp., November 2001.

[SSA02] “SSH Secure Shell for Servers Version 3.2 Administrator’s Guide”, http://www.ssh.com, SSH Communications Security Corp., May 2002.

[SSQ02] “SSH Secure Shell for Servers Version 3.2 Quick Start Guide”, http://www.ssh.com, SSH Communications Security Corp., May 2002.

[Sta98] W. Stallings, “Cryptography & Network Security: Principles & Practice”, Prentice Hall, 1998.

[SWQ02] “SSH Secure Shell for Windows Servers Version 3.2 Quick Start Guide”, http://www.ssh.com, SSH Communications Security Corp., May 2002.

[SWT01] D. Song, D. Wagner & X. Tian, “Timing Analysis of Keystrokes and SSH Timing Attacks”, In 10th USENIX Security Symposium, Washington, D.C. August 13 - 17, 2001.

[SWW02] “SSH Secure Shell for Workstations Windows Client Version 3.2 UserManual”, http://www.ssh.com, SSH Communications Security Corp., May 2002.

[ZCC00] E. D. Zwicky, S. Cooper & D. B. Chapman, “Building Internet Firewalls”, 2nd Edition, O'Reilly, June 2000.