2FA

The vast majority of setups that rely on SSH do not provide support for a second factor. The classic setup with SSH keys only handles 2FA with some add-ons, whereas it is an essential part of the entire authentication process in Teleport.

Teleport hides the X.509 certificates from users because they don't need to be familiar with the technical details of certificate handling to use Teleport. The Teleport shell is a separate client for user logins with their usernames, passwords, and a second factor. The SSL certificate for the client is then issued in the background. Teleport is far more secure out of the box than standard key-based SSH.

Access to Other Services

Another unique selling point for Teleport is that it can run both as an SSH server and as a gateway for any protocol in any direction. SSH mainly benefits.

The example I referred to earlier of connections across multiple jump hosts is very easy to implement in Teleport. In the background, Teleport keeps its own list of machines that belong to the overall setup. The developers call this a cluster. Each machine running the Teleport Node service (the Teleport daemon with the node role) belongs to the same cluster. The SSL certificates Teleport issues are valid throughout the cluster; once a user has been authenticated on their own client, the certificate indirectly gives them access to all available resources.

In terms of node discovery, Teleport uses several mechanisms. Teleport nodes can be discovered by the classic domain name service (DNS). However, this is not the last word, because Teleport comes with its own discovery protocol (Figure 2). Under the hood, it is far more complex than you might expect.

Figure 2: Teleport comes with its own node discovery protocol at the proxy level, making complex jump host setups a thing of the past. © Teleport

The proxy servers I mentioned earlier play an important role here because multiple instances are possible – high availability is an essential part of the Teleport strategy. Proxy servers from the same cluster communicate with each other and exchange information about the target systems they can see. In this case, "see" means that the Teleport node component is active on a node: If you install the node component on a target system, you are basically running a number of commands to add the system to the existing cluster and specifying at least one of the existing proxy servers as the target for the join command.

When done, any target system can talk to any proxy server; in turn, the Teleport proxy servers can be nested conveniently. Proxy 1 then receives information about all visible nodes from Leaf proxy 1 and shares it with the other existing Teleport proxies. A client that wants to connect to a target system therefore only needs to know its IP address or hostname. The user, on the other hand, no longer needs to remember which path they have to take through a mess of nested networks to reach their destination. This path is set up dynamically between the Teleport client and the proxy to which the client connects in the first step.

This arrangement is very practical, especially in the context of high availability. If you install a load balancer upstream of your Teleport proxies, the client only has to remember one address and can be certain of reaching any other host in the setup from any of the proxies running behind it. Modern setups that are broken down into multiple network segments and demilitarized zones (DMZs; subnetworks that contain and expose external-facing services to the Internet) and that implement extensive security measures see a huge convenience gain.

Security and Compliance

Built-in certificate management and the solution of the jump host problem are sufficient added value – compared with commercially available solutions – to justify the use of Teleport. However, the benefits Teleport offers are still far from exhausted. Importantly, the Teleport developers have given a great deal of thought to the issues of security and compliance.

If you operate Teleport in an environment that handles highly sensitive data, you might also be subject to strict legislation. In Teleport's home market, this legislation includes the Health Insurance Portability and Accountability Act (HIPAA), which defines strict standards for handling health data in the United States. Anyone who has squared up to compliance legislation will find many specifications and guidelines in HIPAA that are also found in relevant regulations in Europe, above all in the General Data Protection Regulation (GDPR).

Teleport is officially certified under the HIPAA rules. But in Europe, certification according to the rules of the System and Organization Controls (SOC) 2 guideline is available and likely far more important because it does not stick to US-specific laws but is an accepted standard in the industry for applications related to security-relevant data. In other words, deploying Teleport in your environment if you are in Germany will make it easier for you to describe it within the framework of the Federal Office for Information Security (BSI) certification, because a matching report for this certification is readily available from the Teleport developers.