Version negotiation, Key and algorithm negotiation, Authentication – H3C Technologies H3C SecPath F1000-E User Manual
Page 162
151
Stages Description
After the server grants the request, the client and the server start to
communicate with each other.
Version negotiation
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.
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.
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 in the preceding steps are transferred in plain text.
Key and algorithm negotiation
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.
IMPORTANT:
Before the key and algorithm negotiation, the server must have already generated a DSA or RSA key pair,
which is not only used for generating the session key and session ID, but also used by the client to
authenticate the identity of the server. For more information about DSA and RSA key pairs, see
VPN
Configuration Guide.
Authentication
SSH supports the following authentication methods: