SSH operation
To establish an SSH connection and communicate with each other through the connection, an SSH client and the SSH server go through the stages listed in Table 16.
Table 16: Stages in session establishment and interaction between an SSH client and the server
Stages | Description |
|---|---|
SSH1 and SSH2.0 are supported. The two parties negotiate a version to use. | |
SSH supports multiple algorithms. The two parties negotiate algorithms for communication, and use the DH key exchange algorithm to generate the same session key and session ID. | |
The SSH server authenticates the client in response to the client's authentication request. | |
After passing authentication, the client sends a session request to the server. | |
After the server grants the request, the client and the server start to communicate with each other. |
Version negotiation
The server opens port 22 to listen to connection requests from clients.
The client sends a TCP connection request to the server.
After the TCP connection is established, the server sends a packet that carries a version information string to the client. The version information string is in the format SSH-<primary protocol version number>.<secondary protocol version number>-<software version number>. The primary and secondary protocol version numbers constitute the protocol version number. The software version number is used for debugging.
After receiving the packet, the client resolves the packet and compares the server's protocol version number with that of its own. If the server's protocol version is lower and supportable, the client uses the protocol version of the server; otherwise, the client uses its own protocol version. In either case, the client sends a packet to the server to notify the server of the protocol version that it decides to use.
The server compares the version number carried in the packet with that of its own. If the server supports the version, the negotiation succeeds and the server and the client proceed with key and algorithm negotiation. Otherwise, the negotiation fails, and the server breaks the TCP connection.
![[NOTE: ]](images/note.png) | NOTE: All the packets involved in the preceding steps are transferred in plain text. | |
Key and algorithm negotiation
Before the key and algorithm negotiation, the server must have already generated DSA, ECDSA, or RSA key pairs. The key pairs are used in generating the session key and session ID. The client also uses the key pairs to authenticate the server. For more information about DSA, ECDSA, and RSA key pairs, see "Managing public keys."
The server and the client send algorithm negotiation packets to each other, notifying the peer of the supported public key algorithms, encryption algorithms, Message Authentication Code (MAC) algorithms, and compression algorithms.
Based on the received algorithm negotiation packets, the server and the client figure out the algorithms to be used. If the negotiation of any type of algorithm fails, the algorithm negotiation fails and the server tears down the connection with the client.
The server and the client use the DH key exchange algorithm and parameters such as the host key pair to generate the session key and session ID, and the client authenticates the identity of the server.
Through the steps, the server and the client get the same session key and session ID. The session key will be used to encrypt and decrypt data exchanged between the server and client later. The session ID will be used to identify the session established between the server and client and will be used in the authentication stage.
Authentication
SSH supports the following authentication methods:
Password authentication—The SSH server uses AAA for authentication of the client. During password authentication, the SSH client encrypts its username and password, encapsulates them into a password authentication request, and sends the request to the server. After receiving the request, the SSH server decrypts the username and password, checks the validity of the username and password locally or by a remote AAA server, and then informs the client of the authentication result. If the remote AAA server requires the user for a password re-authentication, it carries a prompt in the authentication response sent to the client. The prompt is transparently transmitted to the client, and displayed on the client to notify the user to enter a specified password. After the user enters the correct password and passes validity check on the remote AAA server, the server returns an authentication success message to the client.
Publickey authentication—The server authenticates the client by using the digital signature. During publickey authentication, the client sends the server a publickey authentication request that contains its username, public key, and publickey algorithm information. The server checks whether the public key is valid. If the public key is invalid, the authentication fails. Otherwise, the server authenticates the client's digital signature. Finally, the server sends a message to the client to inform it of the authentication result. The switch supports using the publickey algorithms RSA, DSA, and ECDSA to generate and verify digital signatures.
An SSH2.0 server might require the client to pass both password authentication and publickey authentication or either of them. However, if the client is running SSH1, the client only needs to pass either authentication, regardless of the requirement of the server.
The following gives the steps of the authentication stage:
The client sends the server an authentication request that includes the username, the authentication method, and the information related to the authentication method (for example, the password in the case of password authentication).
The server authenticates the client. If the authentication fails, the server sends the client a message to inform the client of the failure and the methods available for re-authentication.
The client selects a method from the list to initiate another authentication.
The preceding process repeats until the authentication succeeds or the number of failed authentication attempts exceeds the maximum of authentication attempts. In the latter case, the server tears the session down.
| NOTE: Only clients running SSH2.0 or a later version support password re-authentication that is initiated by the switch acting as the SSH server. | |
Session request
After passing authentication, the client sends a session request to the server, and the server listens to and processes the request from the client. If the server successfully processes the request, the server sends an SSH_SMSG_SUCCESS packet to the client and goes on to the interaction stage with the client. Otherwise, the server sends an SSH_SMSG_FAILURE packet to the client to indicate that the processing has failed or it cannot resolve the request.
Interaction
In this stage, the server and the client exchanges data as follows:
The client encrypts and sends the command to be executed to the server.
The server decrypts and executes the command, and then encrypts and sends the result to the client.
The client decrypts and displays the result on the terminal.
In the interaction stage, you can paste commands in text format and execute them at the CLI. The text pasted at one time must be within 2000 bytes. Hewlett Packard Enterprise recommends you to paste commands in the same view. Otherwise, the server might not be able to execute the commands correctly.
To execute commands of more than 2000 bytes, save the commands in configuration file, upload it to the server through Secure FTP (SFTP), and use it to restart the server.