SSH Technology White Paper

Keywords: SSH, SFTP, RSA, DSA, DES, AES, AAA

Abstract: Secure Shell (SSH) offers an approach to logging into a remote device securely and performing secure file transfer. By encryption and authentication mechanisms, it protects devices against attacks such as plain text password interception and server spoofing. This document provides the background, security mechanisms, operation procedures, and applications of SSH as well as the technical characteristics of the Comware implementation.

Acronyms:

Acronym

Full spelling

AAA

Authentication, Authorization, Accounting

AES

Advanced Encryption Standard

DES

Data Encryption Standard

DSA

Digital Signature Algorithm

FTP

File Transfer Protocol

MAC

Message Authentication Code

RSA

Rivest Shamir and Adleman

SFTP

Secure File Transfer Protocol

SSH

Secure Shell

Stelnet

Secure Telnet

 



Overview

Background

Before SSH emerged, the most popular protocol used in network device management was Telnet. The Telnet protocol allows network administrators to log into remote network devices to perform configurations, implementing easy management of remote network devices. However, Telnet has three fatal weaknesses:

l          Telnet transmits data in plain text, providing no protection for data transmitted.

l          Telnet uses the traditional password authentication mechanism and transmits user authentication information over the network in plain text, making it easy to be eavesdropped.

l          A Telnet client has no way to identify the identity of the Telnet server, namely the remote device. Attackers can easily initiate server spoofing attacks.

SSH was introduced to solve all the previously mentioned problems.

Another popular protocol, File Transfer Protocol (FTP), also faces the similar problems, and the protocol introduced to solve these problems is Secure File Transfer Protocol (SFTP), which is based on SSH.

Benefits

Secure Shell (SSH) offers an approach to logging into a remote device securely and performing secure file transfer. By using encryption and authentication mechanisms, it protects devices against attacks such as plain text password interception and server spoofing.

SSH features the following advantages:

l          SSH transmits data in cipher text, ensuring the confidentiality of the information exchanged.

l          SSH transmits user authentication information in cipher text, efficiently avoiding user identity information eavesdropping.

l          In addition to the traditional password authentication, an SSH server provides multiple user authentication methods (for example, public key authentication, which features higher security) to improve the strength of user authentication.

l          The encryption and decryption keys for communication between SSH servers and SSH clients are dynamically generated in dynamic key exchange processes. Such keys are very hard to get cracked and have much higher security than manually configured keys.

l          SSH clients can authenticate the identities of their servers, avoiding being spoofed by pseudo servers.

Protocol Architecture

Figure 1 Protocol architecture

 

As shown in Figure 1, the SSH protocol uses the client/server model and consists of three layers: transport layer, authentication layer, and connection layer.

SSH Transport Layer Protocol

The SSH transport layer protocol is used to establish a secure, encrypted channel between the server and client, and to provide confidentiality for phases that require higher transmission security, such as the user authentication phase and data exchange phase.

The SSH transport layer protocol supports these functions:

l          Checking data reality

l          Checking data integrity

l          Allowing the client to authenticate the server.

The SSH transport layer protocol typically runs on top of TCP/IP (the well-known port number of the server side is 22). It can also runs over any other type of reliable connection.

SSH Authentication Layer Protocol

The SSH authentication layer protocol runs over the SSH transport layer protocol to allow the server to authenticate clients logging in.

SSH Connection Layer Protocol

The SSH connection layer protocol divides an encrypted channel into multiple logical channels to run different applications. It operates on top of the authentication layer protocol to provide services such as interactive sessions and remote execution of commands.

Security Mechanisms

Ensuring the Confidentiality of Transmitted Data

To solve the flaw of plain data transmission in Telnet and ensure the confidentiality of data transmission, SSH takes these measures:

l          Establishing an encrypted channel between two peers to ensure that data is not eavesdropped during transmission.

l          Using key exchange algorithms to guarantee the security of keys.

Using Encrypted Channel to Protect Data Against Eavesdropping

With an encrypted channel, the sender encrypts data through the encryption key before transmitting the data to the receiver, and the receiver decrypts the received data through the decryption key.

There are two types of encryption/decryption algorithms:

l          Symmetric algorithm: The encryption process and decryption process use the same key and algorithm.

l          Asymmetric algorithm: The encryption process and decryption process use different keys, the public key and the private key respectively, where the private key is kept secret by the client.

As asymmetric algorithms usually take more time, they are usually used for digital signature and identity authentication. Encryption and decryption on an SSH channel are mainly implemented by symmetric algorithms. Currently supported algorithms include Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). These algorithms can effectively prevent eavesdropping and, using initialization vector (IV) for protection, prevent attacks from password analyzing tools, such as reused key attack.

Using Key Exchange Algorithm to Ensure Security of Keys

A symmetric algorithm requires that the decryption key be the same as the encryption key to decrypt ciphered data successfully. Therefore, to establish an encrypted channel, two peers must have the same key. Manual configuration and third-party assignment are two of the methods for deploying keys. The former has the disadvantage of low extensibility, and therefore applies to only small local networks. The latter requires an extra third-party server and keys may be eavesdropped during transmission.

SSH supports using a key exchange algorithm to deploy keys. By a key exchange algorithm, two peers can dynamically generate their key, which only the two peers can obtain and no one else can eavesdrop. This ensures the security of keys and solves the deployment problem.

Here is how a key exchange algorithm works:

1)        The client generates a random number Xc (1<Xc<p-1) as the private key, calculates Yc=g^Xc mod p, and sends Yc to the server. Here, p is a large safe prime, and g is a generator for a subgroup of GF(p). P and G are a pair of parameters that the two peers share. The SSH protocol allows the two peers to negotiate the values of p and g.

2)        The server also generates a random number Xs (1<Xs<p-1), calculates Ys=g^Xs mod p, and sends Ys to the client.

3)        When the server receives Yc from the client, it uses the following formula to calculate the key: K=(Yc)^Xs mod p

4)        When the client receives Ys from the server, it uses the following formula to calculate the key: K=(Ys)^Xc mod p

Now, the client and server have the same key.

As the previous procedure shows, security of a key exchange algorithm depends on the difficulty of the discrete logarithm. In expression Y=g^x mod p, it is easy to calculate Y with x, but it is very difficult to calculate x with Y. In a key exchange algorithm, only p, g, Yc, and Ys are public, Xc and Xs are private. Even if a third-party obtains p, g, Yc, and Ys, it is very difficult to calculate Xc and Xs. In this way, security of keys is ensured.

Key exchange algorithms feature the following advantages:

l          Better extensibility and no manual configuration.

l          Keys are saved in memory and hard to be read or tampered.

l          Each connection generates a new key dynamically. Thus, key security is further improved.

 

Safe Prime and generator are terms in discrete mathematics. For detailed inforamtion, refer to relevant materials.

 

Perfect User Authentication Mechanism

To prevent illegal users from logging into network devices to perform destructive configurations, SSH provides multiple user authentication methods to improve the strength of user authentication. In addition to commonly used user authentication methods including password authentication and public key authentication, the Comware V5 platform offers a new authentication method, that is, password-publickey authentication.

Password Authentication

SSH can employ the authentication function provided by the Authentication, Authorization, and Accounting (AAA) architecture to implement password authentication of users. Depending on the authentication policy used by AAA, password authentication can be local or remote.

Local authentication

Figure 2 Network diagram for local authentication

 

With local authentication, user information is saved on the SSH server and authentication of clients is performed locally. As shown in Figure 2, an administrator wants to log in to the gateway of the community remotely to perform configuration. The gateway acts as the SSH server and authenticates the client by using the user information saved in the local user information database of AAA.

Remote authentication

Figure 3 Network diagram for remote authentication

 

With remote authentication, user information is saved on a remote authentication server such as a RADIUS server, and the network device cooperates with the authentication server to authenticate users. As shown in Figure 3, an administrator wants to log into the gateway of the community remotely to perform configuration. The gateway acts as the SSH server and forwards the authentication information of the client to the RADIUS server for authentication. Then, it determines whether to permit the user by the authentication result from the RADIUS server.

Remote authentication features centralized configuration and management of users, which not only facilitates user management, but also improves user information security. However, this authentication mode requires that the connection between the SSH server and the authentication server is absolutely secure.

Public Key Authentication

As the strength of password authentication is relatively low, the SSH protocol supports public key authentication. Currently, the device supports using RSA and DSA asymmetric key algorithms to implement public key authentication.

The public key authentication process goes through two steps:

1)        Public key authentication: The client sends the public key of its key pair as a string to the server. The server compares the received public key of the client against that locally maintained, thereby checking the validity of the public key.

2)        Digital signature authentication: If the public key authentication succeeds, the client uses the private key of its key pair to perform digest calculation of a specific packet and then sends the result, namely the digital signature, to the server to prove its identity. The server uses the locally maintained public key of the client to authenticate the signature of the client.

If either of the public key authentication and digital signature authentication fails, the authentication of the user fails.

Public key authentication features these advantages:

l          High authentication strength, protecting the system against attacks such as password crack.

l          Easier to use. Once configured, the authentication can go on automatically, without requiring users to provide passwords.

However, public key authentication also has disadvantages:

l          Compared with password authentication, public key authentication is more complex to be configured.

l          Public authentication can only distinguish users by their private keys. To implement more granular security control, every user must have a private key and the server must be configured with the public key of every user. This is obviously neither proper nor necessary for scenarios where multiple users use the same terminal to log in.

Password-Publickey Authentication

The Comware V5 platform defines a new authentication method: password-publickey authentication. This method requires that users must pass both public key authentication and password authentication.

The password-publickey authentication method combines the advantages of password authentication and public key authentication:

l          It requires that users must pass both password authentication and public key authentication, and therefore can provide higher security. By binding the password with the public key, this method can prevent the security risks of a SSH client from affecting the security of the SSH server.

l          This method allows you to configure a single key pair for a group of users, and specify different passwords and authorize different rights for the users, facilitating user management.

l          This method not only makes use of the security of public key authentication, but also reduces the cost in saving and configuring keys. With public key authentication, you need to configure one key pair for every user to implement more granular user authentication. With password-publickey authentication, however, you can configure multiple users to share the same key pair.

l          This method can corporate with the existing Comware V5 feature of AAA to use the various functions of remote servers.

Defense Against Server Spoofing

The user authentication mechanisms allow the server to authenticate its clients but provide no way for clients to authenticate the server, leaving attackers the chance to disguise themselves as the server.

Figure 4 Server spoofing

 

As shown in Figure 4, when a client tries to establish a connection with the server, an attacker may disguise itself as the server to interact with client to obtain the identity information of the client. Then, the attacker may use the identity information of the client to log into the real server, so as to access the resources on the server or attack the server.

To prevent such attacks, SSH enables the clients to authenticate the server. In the key exchange phase, the server uses its private key to add a digital signature to some data in a fixed format and sends the signature to the client. The client uses the locally saved public key of the server to authenticate the signature, so as to authenticate the server.

This mechanism for a client to authenticate the server assumes that the server side public key that the client keeps is really the server’s public key. Therefore, it is critical to guarantee that the client obtains the right server side public key. Currently, Comware V5 provides two methods for obtaining the public key of a server.

l          Manual configuration: You can manually configure the public key of a server on a client and associate the public key with the server’s name.

l          First-time authentication: During SSH protocol interactions, the sever sends its public key through a protocol packet to the client. Based on this, Comware V5 allows you to enable first-time authentication on SSH clients. With first-time authentication, when an SSH client not configured with the server’s public key accesses the server for the first time, it can get the server’s public key from the protocol packet and save the key locally for future use. For details, refer to First-Time Authentication.

Operation of SSH

SSH packet exchange goes through these phases:

l          Connection Setup

l          SSH Version Negotiation

l          Algorithm Negotiation

l          Key Exchange

l          User Authentication

l          Service Request

l          Data Transmission and Connection Teardown

Connection Setup

The SSH server listens to connection requests from clients on port 22. After detecting a connection request, it performs three handshake operations to establish a TCP connection. All subsequent packet exchanges will go on over this TCP connection.

SSH Version Negotiation

After the TCP connection is established, the server and client notify each other of the supported SSH version and compare the peer’s version with its own version. The highest version that both the server and client support will be used.

 

SSH1.99 is a specical version in that it can commumucate with both SSH2.0 and SSH1.5.

 

If the version negotiation is successful, the server and the client proceed with algorithm negotiation; otherwise, the server breaks the TCP connection.

Algorithm Negotiation

Exchange of SSH protocol packets require multiple algorithms:

l          Key exchange algorithm for generating the session key, which can be Diffie-Hellman-group-exchange-SHA1, Diffie-Hellman-group1-SHA1, or Diffie-Hellman-group14-SHA1.

l          Encryption algorithm for data encryption, which can be 3DES-CBC, AES128-CBC, or DES-CBC.

l          Host public key algorithm for digital signature and authentication, which can be RSA or DSA.

l          Message Authentication Code (MAC) algorithm for protecting data integrity, which can be HMAC-MD5, MHAC-MD5-96, HMAC-SHA1 or HMAC-SHA1-96.

As different clients and servers may support different algorithms, a client and its server need to negotiate the algorithms to be used.

The algorithm negotiation goes through three steps:

1)        The client and server send a list of the supported algorithms to each other.

2)        The two peers negotiate each type of algorithm in this procedure: Get the first algorithm of the type from the client’s algorithm list and match it against the server’s algorithm list. If a match is found, negotiation of the algorithm type succeeds and the matching process ends. Otherwise, get the next algorithm of the type from the client’s algorithm list and match it against the server’s algorithm list. This process continues until a match is found or the peers find that they have no algorithm of the type in common, in which case negotiation of the algorithm type fails.

3)        If the negotiation of an algorithm type succeeds, the peers continue to negotiate other types of algorithms. If the negotiation of any algorithm type fails, the algorithm negotiation between the peers are considered a failure and the server will break the connection with the client.

The following table takes the encryption algorithm as an example to show the algorithm negotiation process:

Encryption algorithms that the client supports

Encryption algorithms that the server supports

Negotiated encryption algorithm

3DES, 3DES-CBC, AES128-CBC

AES128-CBC,

3DES-CBC, DES-CBC

3DES-CBC

 

Key Exchange

After the algorithm negotiation process ends successfully, the SSH server and client generate and exchange the encryption key dynamically and securely to ensure the security of the key. This can prevent the key from being intercepted by any third-party. For details about key exchange algorithm, refer to Using Key Exchange Algorithm to Ensure Security of Keys.

User Authentication

After the key exchange process is complete, the user authentication process begins.

Figure 5 User authentication process

 

 

As shown in Figure 5, the user authentication procedure is as follows:

1)        The client sends to the server an authentication request packet, which specifies the authentication method of none.

2)        When receiving the authentication request, the server responds with an authentication challenge packet, which carries a list of the authentication methods that it supports and the client must pass.

3)        The client selects an authentication method from the list and initiates an authentication request, which carries its username, authentication method, and information relevant to the authentication method:

l          For password authentication, the information is the client’s password.

l          For public key authentication, the information is the public key of the client’s local key pair (during public key authentication) or the digital signature (during digital signature authentication).

4)        When the server receives the authentication request, it authenticates the client:

l          For password authentication, the server compares the username and password of the client with those locally maintained or sends them to the remote authentication server to authenticate the client.

l          For public key authentication, the server checks the validity of the public key of the client. If the public key is invalid, the authentication fails; otherwise, the server checks the validity of the digital signature to authenticate the client.

5)        Based on the locally maintained configurations of the client and whether the client has passed the previous authentication, the server determines whether to authenticate the client further:

l          If the client passed the last authentication and no other type of authentication is required for the client, the server sends to the client a success notification.

l          If the client passed the last authentication but must pass other types of authentication, the server sends to the client an authentication challenge that carries the authentication types that the client must also pass.

l          If the client failed the last authentication but the number of authentication attempts has not reached the limit, the server resends the authentication challenge to the client.

l          If the client failed the last authentication and the number of authentication attempts has reached the limit, the server sends to the client an authentication failure notification and tears down the connection with the client.

 

An authentication challenge carries a list of the authentication types that the client has not passed and must pass. Upon receiving an authentication challenge, the client selects one authenticaiton type and initiates the authentication.

 

Service Request

SSH supports multiple services. After the SSH client passes all types of authentication that the server requires, it sends a service request to the server to apply for a service.

The following details the service request procedure:

1)        The client sends an SSH_MSG_CHANNEL_OPEN message to initiate a session with the server.

2)        Upon receiving the SSH_MSG_CHANNEL_OPEN message, the server responds with an SSH_MSG_CHANNEL_OPEN_CONFIRMATION message to establish a session with the client if it supports the requested session type.

3)        After the session is established, the client applies for the shell (SSH) or subsystem (SFTP) service.

Data Transmission and Connection Teardown

After the service request is granted and the session is established, the server and client can exchange data securely through the session as follows:

1)        The client encrypts and sends the command to be executed to the server.

2)        Upon receiving the packet, the server decrypts the packet, executes the command, and sends the result to the client.

3)        The client displays the result on the screen.

4)        After the communication is over or the client is timed out for it has been idle for too long, the session is closed and connection is torn down.

Technical Characteristics

Supporting Two Applications

Currently, Comware V5 supports two types of SSH applications: SSH and SFTP.

SSH

In Comware V5, Stelnet is often referred to as SSH. Using the secure channel provided by the SSH protocol, Stelnet implements secure remote access to network devices. Stelnet is one of the basic applications of SSH.

Currently, Comware V5 provides both the SSH client and SSH server features, where the SSH client is based on SSH2.0, while the SSH server supports both SSH1.5 and SSH2.0. As SSH1.5 and SSH2.0 are not compatible, a device running the Comware SSH client can communicate with only a server running SSH2.0, but a device running the Comware SSH server can communicate with clients running SSH1.5 or SSH2.0.

SFTP

SFTP uses the SSH connection to provide secure data transfer. It is an important, extended SSH application.

Currently, Comware V5 provides both the SFTP client and SFTP server features

First-Time Authentication

To allow an SSH client to authenticate a server, the Comware provides two ways for the client to obtain the server’s public key: manually configuring the server’s public key on the client or configuring the client to obtain the server’s public key when accessing the server for the first time. The latter is called the first-time authentication feature.

l          Without first-time authentication, a client not configured with the server’s public key cannot access the server because it cannot authenticate the server. To access the server, the client must be configured with the server’s public key manually in advance.

l          With first-time authentication, when an SSH client not configured with the server public key accesses the server for the first time, it can obtain the server’s public key from the protocol packet and save the key locally. When accessing the server again, the client will use the locally saved server public key to authenticate the server.

Password-Publickey Authentication

Comware defines a new authentication method called password-publickey authentication. For details, refer to Password-Publickey Authentication.

Application Scenario

SSH is used on insecure networks to support applications such as secure remote access and file operations by implementing a series of encryption and authentication mechanisms. As shown in Figure 6 and Figure 7, the SSH client can access the SSH server securely through a local connection or WAN connection established with the SSH server.

Figure 6 SSH channel through a local connection

 

Figure 7 SSH channel through a WAN connection

 

References

l          RFC 4251: The Secure Shell (SSH) Protocol Architecture

l          RFC 4252: The Secure Shell (SSH) Authentication Protocol

l          RFC 4253: The Secure Shell (SSH) Transport Layer Protocol

l          RFC 4254: The Secure Shell (SSH) Connection Protocol

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright ©2009 Hangzhou H3C Technologies Co., Ltd. All rights reserved.

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd.

The information in this document is subject to change without notice.