1. Getting Started

This manual is designed to help you learn everything you need to know about the individual components of the suSSHi Suite. In addition, we want to provide some configuration examples for target servers, common SSH clients and other tools, that use SSH as a secure protocol.

Note

We do our best to keep these pages up to date and complete, but we are still working on the further development of the site, so it is worth visiting from time to time.

To better understand what suSSHi is used for, first let’s look at the SSH protocol.

1.1. SSH Protocol

SSH is a protocol, not a product. The Secure Shell (SSH) protocol is a specification of how to conduct secure communication over a network. It covers authentication, encryption, and the integrity of data transmitted over a network, as shown in the diagram below.

SSH is the de facto standard for accessing servers, network devices and a number of services like Git in a secure and reliable way over the network. OpenSSH is one of the most popular and widely used SSH server and client implementation of this genre, but there are many others available as open source software or commercial products.

1.1.1. Protocol Overview

_images/ssh_protocol.png

Modern SSH servers and clients such as OpenSSH Version 7.x and higher, no longer support the older SSH1 protocol, which in many respects has long been obsolete. For this reason, suSSHi only supports the current SSH2 protocol, which is documented in various RFCs and thus represents an Internet protocol standard.

See also

See Compatibility for references to RFC standards that describe the SSH protocol.

We won’t cover all the basics about SSH - there are many sources available on the Internet - but we will focus on the steps and actions that happen during an SSH session to connect with an SSH client to an SSH server. Basically, an SSH server is a server process running on the (target) server system a user wants to connect to, in order to execute some commands or copy files, and so on.

1.1.2. Phases in SSH

We now simply assume that we have a correctly configured SSH server process running on a target system on TCP port 22 and that a common SSH client is used on the client.

  1. Connection

    After the user calls up the SSH client and provides it with the destination address (name or IP of the server, possibly another TCP port than 22) and a username, the SSH client first tries to establish a TCP connection to the destination server on port 22 or the port just specified.

  2. Banner Exchange

    In a second step, the two sides exchange their SSH banners in plain text to signal the other side that an SSH server with protocol version 2 is running here.

  3. Parameter negotiation

    In the next step, step 3, various parameters such as the encryption and hash algorithms to be used are negotiated.

  4. Server authentication

    In step 4, the server sends the public key of its SSH host key pair, which must then be verified by the client. This is usually done by displaying the sent public key to the user at the very first connection to a new destination in the form of a SHA256 hash and confirming its correctness. It is then stored in the known_hosts file and repeatedly verified against this stored entry for future connections. This check ensures the unique identity of a server and prevents man-in-the-middle attacks.

  5. SSH Authentication protocol

    In step 5, a very complex phase of user authentication follows, in which the server authenticates the user by querying for corresponding credentials from the client. In the simplest case, this can be a password or a keyboard-interactive authentication, but the most secure is authentication with the user’s public key. The public key authentication method uses RSA, DSA or ED25519 key material to securely authenticate the user.

  6. SSH Connection protocol

    In the last phase, the SSH Connection Protocol (RFC 4254) takes place, which is also spoken during the entire session. Further control of the requests and multiplexed channels takes place in this protocol.

1.2. SSH Gateway

suSSHi operates as a so-called non-transparent proxy or gateway between the 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.

By placing the suSSHi Gateway so that the user can reach it via SSH, and the suSSHi Gateway in turn can reach the target servers, an secure access control system for SSH connections can be implemented. This provides a lot of additional security, monitoring capabilities and centralized access control for secure communication between clients and servers in all SSH phases.

Note

With standard SSH implementations like OpenSSH, you have to configure all the access control, user mappings, etc. on each target, and controlling what a client is allowed to do on the server quickly becomes a nightmare.