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 13.

1. The server opens port 22 to listen to connection requests from clients.

2. The client sends a TCP connection request to the server.

3. 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.

4. Upon 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.

5. 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: All the packets involved are transferred in plain text.

1. The server and the client send algorithm negotiation packets to each other, which include the supported public key algorithms list, encryption algorithms list, Message Authentication Code (MAC) algorithms list, and compression algorithms list.

2. 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.

3. 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.

	CAUTION: Before the negotiation, the server must have already generated a DSA or RSA key pair, which is not only used for generating the session key, but also used by the client to authenticate the identity of the server. For more information about DSA and RSA key pairs, see the chapter "Public key configuration."

SSH provides password authentication and publickey authentication.

• Password authentication—The server uses AAA for authentication of the client. During password authentication, the client encrypts its username and password, encapsulates them into a password authentication request, and sends the request to the server. Upon receiving the request, the 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.

• Publickey authentication—The server authenticates the client by the digital signature. During publickey authentication, the client sends to 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 by the digital signature. Finally, the server sends a message to the client to inform the authentication result. The device supports using the publickey algorithms RSA and DSA for digital signature.

The following gives the steps of the authentication stage:

1. The client sends to the server an authentication request, which includes the username, authentication method—password authentication or publickey authentication, and information related to the authentication method—for example, the password in the case of password authentication.

2. The server authenticates the client. If the authentication fails, the server informs the client by sending a message, which includes a list of available methods for re-authentication.

3. The client selects a method from the list to initiate another authentication.

4. The process repeats until the authentication succeeds or the number of failed authentication attempts exceeds the maximum of authentication attempts and the session will turn down.

   	NOTE: In addition to password authentication and publickey authentication, SSH2.0 also provides the following authentication methods: Password-publickey—Performs both password authentication and publickey authentication if the client is using SSH2.0 and performs either if the client is running SSH1. Any—Performs either password authentication or publickey authentication.

After passing authentication, the client sends a session request to the server, and the server listens to and processes the request from the client. After successfully processing 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.

In this stage, the server and the client exchanges data in the following way:

• 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.

  	NOTE: In the interaction stage, you can execute commands from the client by pasting the commands in text format—the text must be within 2000 bytes. The commands should be in the same view. Otherwise, the server might not be able to perform the commands correctly. If the command text exceeds 2000 bytes, you can execute the commands by saving the text as a configuration file, uploading the configuration file to the server through Secure FTP (SFTP), and then using the configuration file to restart the server.