Bouncer

A decade and a half ago, when security and compliance were not as dominant in some places as they are today, the number of accounts and passwords was something like manageable and many an admin got rid of local accounts altogether in favor of root on their SSH-only machines. Instead, a password for root worked everywhere in the setup and – with a little luck – was encrypted for storage in a central password store somewhere.

Today, however, this practice is completely unthinkable. Various security standards (e.g., Payment Card Industry Data Security Standard, PCI DSS) now stipulate that it must be possible to trace who changed what on which systems and when, which makes individual accounts mandatory. Today, even the toughest deniers of the need for compliance tend to avoid root logins over secure shell (SSH) with just password protection. Most distributions even prohibit this practice in the default configuration. Sudo and SSH keys for individual access are the means of choice instead.

This practice only makes sense, especially in setups where admins are really only entrusted with the operation and maintenance of machines that can be accessed by SSH. However, this is decreasingly the case today. DevOps, the cloud, and containers have made information technology (IT) far more heterogeneous. Kubernetes APIs and databases need credentials, along with various other services, and all of them use their own protocols for authentication.

Even SSH is not quite as clear-cut as it seems at first: In the interest of security, it is quite common today not to run systems with a direct connection to the Internet if they do not need the access. SUSE Manager, Red Hat Satellite, and the like have long since found a solution to the problem of delivering updates and other essential features to systems without a direct Internet connection.

In return, however, such systems can no longer be accessed directly over SSH. Instead, a jump host or cluster workstation is used as a central access point from which the admin can shift onto the target system. To do this, however, you need to remember the sequences of hosts that take you to the destination.

Teleport

One way to approach this problem is with Teleport, which promises to consolidate "connectivity, authentication, authorization, and audit into a single platform to improve security and agility" [1]. The developers do this by eliminating nested SSH jump hosts, standardizing SSH authentication within a setup by issuing and revoking its own Secure Sockets Layer (SSL) certificate authority (CA) and X.509 certificates (instead of relying on simple SSH keys), and adding two-factor authentication (2FA), which is difficult to do in SSH with on-board tools.

The real killer feature of the software, though, is the use of SSH as a tunneling protocol to connect you to services such as Kubernetes, popular databases, and other services, thus converting the SSH server into a multitalented connectivity wizard, which in turn promises to take worries relating to authentication and authorization off your shoulders. In this article, I look at whether these claims pan out and examine the features of Teleport.

Architecture

For a deeper understanding, it is extremely useful to take a look at the Teleport architecture (Figure 1). Under the hood, a Teleport instance comprises three self-sufficient services that are part of the same binary. Teleport comes as a single large Go file. Although the individual parts of Teleport support cluster mode, it is not technically necessary.

Figure 1: At its core, Teleport consists of three components: the proxy, the authentication component, and the node component. All nodes running a Teleport node together form a cluster as a logical unit.

Initially, the Teleport proxy plays a significant role. It listens on the outside for incoming connections and acts as the SSH server (i.e., it speaks the SSH protocol). When it receives an incoming connection from a client, it first communicates in the background with the authentication component, usually abbreviated Auth. The question of whether a client is granted access to a target system is decided there: The Auth component is also a full SSL CA.

If a client logs in to the Auth component directly with a valid X.509 key issued by the Auth component itself, the connection to the target system enters the next phase. If the client uses a combination of a password and username instead, the Auth component first creates a valid X.509 certificate with restricted validity (usually 12 hours) and sends it back to the client. The second phase of establishing the connection then follows.

Teleport is used in node mode in this case. On each node of a Teleport cluster, Teleport also runs as an SSH server in node mode. Once the client has a valid X.509 certificate, it establishes the connection to the target system via the Teleport proxy. A shell is then available to the client here, just as it would be in setups without Teleport.

Experienced admins who are always reluctant to accept fundamental innovations may turn up their noses at this point. Replacing OpenSSH, which many admins know and appreciate, is an invasive intervention in terms of a system's overall architecture, and Teleport doesn't offer that much added value at first glance. After all, you can also use X.509 certificates with plain vanilla SSH. To understand the practical relevance of Teleport, it is worth taking a closer look at the various features that Teleport brings to setups.

Doing More

At the top is Teleport's ability to handle SSL certificates. OpenSSH can also check and evaluate certificates sent by clients on the basis of an existing SSL CA; however, the entire handling of the CA in such a setup is the administrator's responsibility, and any admin who has ever had an SSL CA on their plate can judge the complexity of this undertaking from their own experience.

Teleport at least takes some of the load off the admin's shoulders here, but it does even more: Because Teleport automates certificate handling, it also contributes to security by limiting the validity of any certificate. The certificates issued by Teleport are valid for a maximum of 12 hours, so even if they fall into the wrong hands, the damage can be contained.

Additionally, Teleport largely hides the entire certificate handling process from the user. Admins only have to worry about SSL during the initial setup. Once Teleport is up and running, everything works on its own, which makes everyday administrative work far easier.