2.1. Architecture Overview

2.1.1. SSH Client

Any type of RFC-compliant SSH client software can be used as a client, whether as an SSH console client for interactive connections, or an SFTP or SCP client for file transfers. It is also possible to use clients that only establish a TCP forwarding connection.

In most setups, authentication using public/private key procedures is usually preferred. For this reason, a client should support this authentication method. Furthermore, in cases where the target can only be authenticated by entering additional credentials such as a password, the client also needs to support the Keyboard-Interactive authentication method.

If the special Public Key authentication via suSSHi is to be used, the client also has to support an SSH Authentication Agent.

2.1.2. SSH Server

Any RFC-compliant SSH server that supports the encryption and hashing algorithms of suSSHi can be used on a target system. The most common SSH server is certainly OpenSSH, whose typical configuration will be explained later. Besides OpenSSH, there are many other open source or commercial products.

2.1.3. suSSHi Gateway(s)

The suSSHi Gateways are the only components that are perceived by an end user in a data center or an environment secured by the suSSHi Suite.

Secured data center or environment

In a secured data center or environment, direct SSH access to target servers is commonly prohibited by either a network firewall, security groups or local configuration on the target. suSSHi provides a high sophisticated solution for fine granular access policies and only the IP addresses (or networks) of the suSSHi Gateways are allowed to establish SSH sessions to the targets. This way, the user is forced to use the suSSHi Gateways to connect onto the target without any way around.

suSSHi Gateway is an RFC-compliant gateway for the SSH protocol and, like a proxy, functions as a connection point between a client and a target server. It is used as a central entry point for SSH connections, which simplifies firewall rules and helps protecting servers from direct client access.

The gateway establishes two independent SSH connections: one between the client and suSSHi Gateway and another connection between the suSSHi Gateway and the target system. Having these two independent SSH connections allows for auditing and full control of the SSH payload.

2.1.3.1. Example

All SSH connections from a client to a target are established by connecting to the gateway and provide some information about the target, the target user and the gateway user within the SSH username.

ssh -l johndoe@root@server-01 susshi-gateway.corporate.net

In this example, the user John Doe has a gateway user named johndoe and want’s to login on target server-01 with the target user root. He provides this information to the SSH gateway within the username (-l option). The host, the SSH client connects to, is the suSSHi Gateway (in our example named susshi-gateway.corporate.net) itself.

Let’s take a closer look at suSSHi Chef.

2.1.4. suSSHi Chef

While the gateway acts as a pure Policy Enforcement Point (PEP), suSSHi Chef plays the role of Policy Decision Point (PDP) and Policy Administration Point (PAP).

suSSHi Chef is the central user account, access and configuration management of the suSSHi Suite that comes with sophisticated features as well as advanced integrations and automation options, i.g. a full REST API supports you in gaining full control over content configurations.

A modern user interface, the suSSHi Chef UI, allows administrators to easily use all functions and configuration options to perform the relevant administrative tasks. The UI can be accessed using a standard web browser via an HTTPS connection.

In addition, suSSHi Chef collects session information in the form of short reports that can be easily searched. Active user sessions can also be disconnected at the request of the UI administrator.

A special role of the super administrator allows the management of very central system functions as well as the creation of so-called partitions to reflect multi-tenancy.

The REST-based configuration API allows all items within a partition to be created, modified, read and deleted. API tokens are assigned per partition and restrict access to it.

Please continue reading on suSSHi Chef and its subpages.

2.1.5. suSSHi Database

suSSHi Chef stores all data in a PostgreSQL database, which is not shipped with the suSSHi Chef software. The database can run in any redundancy setup. Currently, PostgreSQL version 11 and 12 are supported.

2.1.6. suSSHi Proxy

suSSHi Proxy completes the suSSHi Suite with an optional proxy component that can be installed at the edge of a protected environment. While suSSHi Proxy can reach any target within the protected environment itself, it acts as a single point of contact.

As the name suggests, the suSSHi Proxy establishes the necessary connection between the suSSHi Gateway and the desired target, which in such a deployment cannot be reached directly by the gateway either for security reasons or due to its IP addressing. In this way, the proxy acts as a kind of extension of the gateway.

2.1.6.1. Example

To address a destination via a proxy, the user specifies the destination server followed by a realm when establishing the connection. This way the gateway can immediately recognise that the desired connection must be routed via the corresponding proxy.

suSSHi Gateway then connects directly to the proxy to be found under this realm and lets it perform the name resolution of the target system. This makes it possible to address target systems that can only be resolved in an isolated namespace within the secure environment.

ssh -l johndoe@root@server-01@proxy-realm susshi-gateway.corporate.net

The example shows that the user John Doe has a gateway user named johndoe and want’s to login on target server-01 with the target user root using the realm proxy-realm. He provides this information to the SSH Gateway within the username (-l option). The host, the SSH client connects to, is the suSSHi Gateway (in our example susshi-gateway.corporate.net) which then routes the connection to the corresponding proxy.

2.1.6.2. Bastion Mode

Another really handy feature is the suSSHi Proxy Bastion mode. Often a user simply wants to open a port forwarding to a secure environment, e.g. to connect to a server via RDP or VNC. Normally, he also needs to have an SSH server within the target network to be able to connect to it via SSH.

For this use case the suSSHi Proxy Bastion mode was developed, which allows to establish (local) port forwarding connections without connecting to a SSH server in the target network. The user connects to the proxy itself and the port forwarding connections continue from there to the desired destinations.

To select this mode, the user simply specifies username@proxy-realm as the user name when connecting to a suSSHi Gateway, so that suSSHi knows that it is a bastion connection via the suSSHi Proxy stored under the proxy-realm.

ssh -l johndoe@proxy-realm -L1443:www.company.com:443 susshi-gateway.corporate.net
ssh -l johndoe@proxy-realm -D1080 susshi-gateway.corporate.net