Authentication of the server to the client

When the client issues an SSH connection request, such as ssh ServerUser@ciscosystem, the server accepts the connection request and responds with the server’s version identification. The client parses the server’s version identification and then sends its own version identification. The purpose of the version-identification exchange is three-fold:

• To validate that the connection is to the correct server port.

  Note:

  The standard SSH port is 22.

• To declare the SSH protocol version number that is used by the server and by the client.

• To declare the software version that is used by the server and by the client.

  The client and server negotiate which SSH protocol version to use.

  The server then sends its public host key and a list of supported ciphers and authentication methods to the client. The client compares the server’s host key to the user’s database of known hosts. If the received host key matches the server’s host key entry in the user’s database, the SSH connection attempt continues.

  If the received host key does not match the server’s host key entry, the client terminates the SSH connection attempt, and informs the user where to find the conflicting key in the user’s database.

  If no host key entry exists for the server in the user’s database, the client responds in one of three ways, depending on the value of the StrictHostKeyChecking parameter in the client’s configuration file:

• StrictHostKeyChecking=ask (default)

  The client asks the user whether to add the server’s host key to the user’s database.

  If the user answers with yes, the client adds the server’s host key to the user’s database and continues the SSH connection attempt.

  If the user answers with no, the client discards the server’s host key and terminates the SSH connection attempt.

• StrictHostKeyChecking=no

  The client automatically adds the server’s host key to the user’s database and continues the SSH connection attempt.

• StrictHostKeyChecking=yes

  The client discards the server’s host key and terminates the SSH connection attempt.

  If the outcome is that the SSH connection attempt should continue, server authentication is established.

  The client then generates a session key, encrypts it with the server’s host key, and sends the encrypted session key and selected cipher to the server. Both sides then turn on encryption using the session key and the selected cipher. The server sends an encrypted confirmation message to the client.