209
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.
Key and algorithm negotiation
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 used
in generating the session key and 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.”
Authentication
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 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 it of the
