SSH-2 uses a layered architecture, consisting of a transport layer, a user authentication layer, and a connection layer (described here).

The previous post in this series explained the transport layer, which provides encryption, host authentication and integrity checking. Encryption and integrity checking ensure that messages sent between client and server cannot be viewed or tampered with. Host authentication means that the client knows it is communicating with the right server.

The next step is for the client to identify itself to the server, and be authenticated. This is managed via the user authentication layer, which runs on top of the transport layer. This means user authentication messages are encrypted and exchangeusing the transport layer

User authentication is initiated by the client with a “service” request for the ssh-userauth service. If the server responds by allowing the request, the client sends an authentication request, which includes their username and the authentication method.

There are a number of possible authentication methods, and which one is used will depend on the client and server’s support for it. The most popular method is password authentication, which is self-explanatory. Another is publickey authentication, which will be explained in more detail in a subsequent post. Typically, the client proposes a method, and the server either accepts or rejects that method.

An example of a password authentication request by a user called “enterprisedt” is shown below:

byte      SSH_MSG_USERAUTH_REQUEST
string    "enterprisedt" [user name]
string    "ssh-userauth" [service name]
string    "password"  [authentication method]
boolean   FALSE
string    "mypassword" [user's password]

The server will validate the password sent for this user against the details it has stored for the user. The server will not store the user’s actual password for validation, but a cryptograpic hash of the password, which cannot be reverse-engineered to obtain the password.

If the user authentication request is rejected (for example, an incorrect password was supplied), a failure message is sent by the server, and it provides a list of alternative authentications that can be tried.

It is common to send “none” as the initial authentication method, and the server will usually respond with a failure message containing a list of all available authentication methods.  An example response to “none” is shown below:

byte         SSH_MSG_USERAUTH_FAILURE
name-list    password,publickey
boolean      FALSE (partial success flag)

Here the server is informing the client that either password or publickey authentication can be used.

If the password authentication request succeeds, the server returns a success message as shown below:

byte      SSH_MSG_USERAUTH_SUCCESS

At this point authentication is complete, and other services can be requested. These will be discussed in subsequent posts, but include TCP/IP forwarding requests, and channels for terminal access, process execution and subsystems such as SFTP.
 
 
Try CompleteFTP in a 30-day free trial