2. suSSHi Architecture

suSSHi functions as a so-called non-transparent proxy between an SSH client and an SSH server, i.e. the servers are protected by suSSHi by preventing direct access, e.g. by a network or host-based firewall or a corresponding host configuration.

For better understanding, the following diagram illustrates the individual components and their relationships:

The SSH Client (any RFC-compliant console, SFTP, SCP, or TCP-forwarding client) initiates a connection to the suSSHi Gateway, the sole SSH entry point in a secured environment and the Policy Enforcement Point for all SSH traffic.

The gateway consults suSSHi Chef, the Policy Decision Point and Policy Administration Point, to authenticate and authorize every session. suSSHi Chef manages users, access policies, and gateway configuration, exposes both a web-based administration UI and a full REST API, and persists all data in a dedicated suSSHi Database.

Once the session is authorized, the gateway establishes a second independent SSH connection to the SSH Server on the target system, which can be any RFC-compliant SSH implementation.

Where targets cannot be reached directly, for instance because IP addressing or security policy prevents a direct connection, the optional suSSHi Proxy extends the gateway’s reach into the protected environment and handles name resolution within isolated namespaces.

Next, we will briefly discuss the components and their roles.