3.3 State machines

This section gives an overview of the library internal working. It describes the finite state machines (FSM) used to implement the ssh2 protocol in the library.

The transport layer is implemented using four finite state machines:

• The main transport FSM tracks the state of the struct assh_session_s object. It manages the different phases of the protocol, starting with exchange of version strings. It also dispatches packets to the running key-exchange module and to the service FSM. It handles disconnection as well.

• The input FSM retrieves the remote ssh stream from the application then extracts, decipher, authenticate and decompress packets.

• The output FSM enciphers outgoing packets and report the output ssh stream to the application for transmission to the remote host.

• The service FSM manages selection and execution of the ssh2 services running on top of the transport layer. On a client session, the service FSM sends service requests to the server, then initializes and run the next service. On a server session, the service FSM waits for client requests, then initializes and run the requested service.

The state of these FSMs are updated when the assh_event_get and assh_event_done functions are called by the application.

The library behaves as follows when the assh_event_get function is called:

• It reports any pending error event.

• It checks for protocol timeouts.

• It dispatches an incoming packet to the running key-exchange module, if any. When none is running, it dispatches to the service FSM instead.

• It lets the running key-exchange or service report an event to the application.

• If no event has been reported, the output FSM is executed, unless disconnected from the remote host. This may report an ASSH_EVENT_WRITE event to the application.

• If no event has been reported by the output FSM, the input FSM is executed, unless disconnecting. This reports an ASSH_EVENT_READ event to the application.

The behavior of the assh_event_done function depends on the reported event. It calls a function provided by the libassh software component that reported the event.

Client and server user authentication components are implemented as two different service modules. They each have their own FSM.

The client user authentication FSM handles authentications requests from the application and forwards them to the remote server.

The server user authentication FSM replies to authentications requests from the remote client under supervision of the application.

The module that implements the connection protocol is identical for server and client sides. It relies on two different types of FSMs that are instantiated for each channel and request objects.

The channel FSM manages the channel protocol state and lifetime. It ensures that any channel object known to the application will be properly reported as released at some point even in case of disconnection.

The request FSM is used to reorder request replies so that the application can handle them out of order.

The various key-exchange modules all use their own FSM in order to execute the key-exchange process. Because these FSMs are very simple and linear, no state diagrams are provided.