The Four Horsemen of SSH

 SSH protocols

ssh protocol is divided into four sections, formally described as four separate protocols in different IETF documents and, in principle, independent of
one another.

• SSH Transport Layer Protocol (SSH-TRANS)
• SSH Authentication Protocol (SSH-AUTH)
• SSH Connection Protocol (SSH-CONN)
• SSH File Transfer Protocol (SSH-SFTP)

SSH is designed to be modular and extensible. All of the core protocols define
abstract services they provide and requirements they must meet but allow multiple
mechanisms for doing so and a way of easily adding new tools. All the critical parameters of an SSH connection are negotiable, including the methods and algorithms used in:
    • Session key exchange
    • Server authentication
    • Data privacy and integrity
    • User authentication
    • Data compression

SSH transport layer protocol

Connection:

request a connection by running an ssh client in verbose mode:

ssh -Vv host.name.com

Protocol Version Selection

The client-side and server-side proceed to select a protocol version that they both support.

If a connection is made, both sides switch to a non-textual, record-oriented communication protocol. This is known as ssh binary packet protocol and is defined in SSH-trans.

After protocol selection, the ssh-trans arrange for basic security preference of the ssh:

• encryption support
• integrity
• server authentification
• compression
  

The negotiation happens in the key exchange phase, where unrelated parameters to the key are exchanged to set the security.

The SSH key exchange algorithm has two outputs:

A shared secret, k.
an exchange hash, h.

K is the master secret for the session: ssh trans defined a method for deriving from secret k the various keys and other cryptographic parameters needed for specific encryption and integrity algorithm used in the ssh connection.

H is not a secret but doesn't need to be divulgated. It should be unique to the session and computed so that each side can force a particular value of hash H.

Authentification is done in the order of the server first, then the client.

The client can be attacked by a spoofing, redirecting its TCP connection to another DNS connection to input personal data, or a man in the middle attack.

The client is identified by submitting a password.

The key exchange is later repeated to replace the ageing master secret or re-authenticate the server. It is recommended that a connection be rekeyed every gigabyte of transmission or one hour later.

The hash output H of the very first key exchange is used as the "session identifier" for this SSH connection.

Next, the client offers a choice of ssh host key type it can accept:

Note that the null is included for Kerberos; it's for host authentification.

After the client list the encryption cypher it supports, the selected cypher is used for the privacy of data flowing over the connection.

Bulk data are not enciphered using the public-key method as it's too slow to encrypt them. Therefore asymmetric encryption is used over the session and protects the session key for that cypher with the public key method.

The client also provides a list of integrity algorithms it supports.

The integrity algorithm is applied to each message sent by the ssh record protocol, together with a sequence number and session key to produce the message authentication code(MAC)

Lastly, the client provides the supported compression technic.

Note that none is also provided to indicate that the client doesn't require any form of data compression.

Note that the ssh speaker also negotiates a language tag for the session to allow the server to send error messages in the language appropriate for the client. (the language tag is defined in RFC-3066)

Key exchange and server authentication

The client chooses an exchange algorithm from the server advertise set.
The client expects, and the server sends its reply to our KEXDH_INIT message.

The reply contained the server's ssh public host key and a signature proving it holds the corresponding private key.

However, this authentication doesn't have any meaning since a malicious person could have generated these keys.

Therefore, the client finds a record associated with the server name with the key supplied by the server. The client verifies if the key is authenticated or not.

Moreover, verifying the owner of a public key is popular, so we have a public key infrastructure system, such as the X509 public-key certificate.

Server authentication and antispoofing: Detailed process

The server signs the SSH session identifier. Recall that the identifier is unique to each session, and neither side can force a particular value on it. So to do a MITM, the attacker has to execute the ssh protocol independently on two sides: once with the client and the server. The identifier for the two connections is guaranteed to be different. He needs to produce the client-side identifier signed by the server to fool the client, but all he can get is the server-side identifier: he can't force the server to sign the wrong identifier.

After establishing a secure connection between the server and the client,
the client can derive the encryption key and integrity key from the master secret. the server does the same procedure

SSH Authentication Protocol (SSH-AUTH)

The authentication process is driven by the client, framed by the client request and server responses. A request containing the following part:

• Username U
• The authorisation the client is claiming. a user account
• Service name S
• The facility to which the client is requesting access and hence implicitly the protocol to be started over the ssh-trans connection after authentication succeeds.
• Method name M, and method-specific data D
• The particular authentication being used in this request- for instance: password, the public key and host authentication

Authentication response

ssh -auth response come in two: success or failure

failure:
    A list of authentication method to continue
    a partial success flag

The "none" Request

the client starts the authentication process by making a process, and the server responds to the available authentication method; then, how will the client know which method is compatible with the server.

Therefore, the protocol reserves a method name none and gives it special meaning: if authentication is required, it should always fail, and a list of authentication methods to continue is sent to the client. If the account doesn't require any authentication, it s granted access immediately.

Public-key authentication

public-key authentication request carries the method name "publickey" and may have a different form depending on a flag set

•     flag = FALSE
•     Algorithm name
•     key Data
  

The usable public key algorithm is the same set defined in ssh trans, and the format key data depend on the type: e.g. ssh -DSS, it contains just the key, or the x509 holds the public key certificate.

The request is just a mere authorisation test with flag- false: it asks the server to check for the public key authorised to access the desired account. If it is a special response, it is sent; else, the response is a failure.

•     flag  TRUE
•     Algorithm name
•     key data
  

This request authentication: the signature is computed over a set of request-specific data, including the session id, which binds the request to this ssh session and gives the public key method its measure of MITM resistance similar to the key exchange described earlier.

Two method is provided due to the compute-intensive task of verifying key and the time constraint.

Password authentication

The password method is the simplest one. The client provides a password to authenticate himself. The server responds to success or failure accordingly.

The password is passed in plain text as far as ssh-auth is concerned. Therefore an encrypted connection is required for this method. Moreover, the method reveals the password to the server. if a connection to an unauthenticated server in ssh-trans is made, ssh disallows password authentication in ssh-auth

Host-based authentication

Host-based authentication is the authentication of the client host. A trust relationship between machines is established.

host-based has the advantage of not typing passwords or passphrase or generating, distributing and maintaining public keys

Host-based auth request has:

• host key algorithm
• client host key
• client hostname
• client-side username, C
• signature
  

Note that the request has two usernames the server-side account name U present in every ssh-auth request and the client-side username c specific to the host-based request.

The user C on the client side is requesting access to user U on the server-side, and the client's authentication as c is vouched for by the signature of the client host key.

The server must verify the client host identity to authorise it from accessing the claim account. It must check that the supplied key matches the claimed client hostname. After that, it then uses the same hostname in the authentication check to see if the requested client name pair is allowed to access from this client host.

SSH Connection Protocol (SSH-CONN)

This layer provides the capabilities that users want to employ directly and defines ssh for most people: remote login and command execution, agent forwarding, file transfer, TCP port forwarding x forwarding and more.

Channel

the basic of ssh conn is to provide multiplexing. Ssh conn take a single secure duplex byte stream offered by ssh trans and allow its client to dynamically create any number of logical ssh conn channel over it. Channels are identified by channel number and destroyed by either side. Channel is individual flow-controlled, and each has a channel type that defines its use.

The define type are:

•     session
• remote execution of a program
•     x11
• an x11 client connection
• one of these is opened from server to client for each x11 program using x forwarding as established by an x11-req on a session channel
•     forward-tcpip
• an inbound connection to a remotely forwarded port
• when a connection arrives on a remotely forwarded TCP port, the server opens this channel back to the client to carry the connection.
  
•     direct-tcpip
• an outbound TCP connection
• This directs the peer to open a TCP connection to a given socket and attach the channel to that connection. The socket may be specified using a domain name or IP address, allowing a name to be resolved on the remote side in a possibly different namespace than the client. These channels are used to implement local TCP forwarding (ssh -L). Preparing for local forwarding is purely a client-side affair: the client simply starts listening on the requested port.* The server first hears of it when a connection arrives on the port, after that the client opens a direct-tcpip channel with the appropriate target socket. This means that if the server disallows certain local forwardings, this isn't noticed on connection setup, but only when a connection is attempted
  

Requests

In addition to an array of channel operations - open-close send data send urgent data etc. ssh defines a set of requests with global or channel scope. A global request affects the state of the connection, whereas a channel request is tied to a particular open channel.

    The global requests are:

•     tcpip-forward
• request a remote TCP port forwarding:
• If the user requests a TCP port be forwarded on the remote side back to the local side(as with ssh -R), the ssh client issue this global request. The server starts listening on the indicated port and creates a forwarded Tcpip channel back to the client for each connection. This request contains the full socket bound on the remote and pair and not just the port number. This allows the client to be selective in remote forwarding remote ports on a multi-homed server or implement local-only remote forwarding by binding only the loopback address(127.0.0.1) per request.

•     cancel Tcpip-forward
• cancel an existing remote forwarding
•     pty-req
• allocate a pty, including window size and terminal modes.
•     x11-req
• set up x11 forwarding
• do the preparation necessary for x11 forwarding on the remote; usually involves listening on a socket for x11 connection setting the display variable to point to that socket, and setting up proxy x11 auth.
• env
• set environment variable
• shell,exec,subsystem
• run default account shell an arbitrary program or an abstract service, respectively
• window-change
• Change terminal window size.
• xon-xoff
• Use client-side ^S/^Q flow control.
• signal
• Send a specified signal to a remote process (as in the Unix kill command).
•  exit-status
• Return the program's exit status to the initiator.
• exit-signal
• Return the signal that terminated the program (e.g., if a remote program dies by signal, as from a segmentation fault or manual kill -9 command).

This article was intended to trace the step of a connection between a client and a server where the 4 layer of ssh operate. Due to little information on the terminal there is a lot of screenshot missing. I will correct it in future.

I hope you find it interesting, see you soon........