Teleport 2.3 Released
Teleport 2.3 Released
Today we are happy to unwrap version 2.3
of Teleport. The focus of this release has been on making
Teleport more pleasant to configure and use.
Teleport was initially developed to be an internal library
that Gravity used to connect distributed Kubernetes clusters. However, its rapid adoption as a standalone tool (over 7,000 stars on Github) has warranted more focus on improving its user experience.
Before we dive into the 2.3 release notes, let us introduce Teleport to new
readers of this blog.
What is Teleport?
Teleport is a modern SSH server designed for distributed teams accessing shared, distributed
infrastructure. It allows teams or organizations to manage trust across their users and compute infrastructure with the following features:

Certificate-based SSH: Teleport removes the need to distribute SSH keys.
Use of SSH jump-hosts / bastions by default.
Built-in SSH audit capabilities with session recording and replay.
Flexible Web UI: SSH into your servers from any OS via browser.
The Enterprise edition includes SSH RBAC with SSO via SAML or OpenID Connect.

Teleport is fully compatible with OpenSSH clients and servers and can be used
just as a bastion, issuing SSH certificates and providing connectivity to
legacy clusters located behind firewalls.
What's new in 2.3?
As usual, the full list of changes can be found on Github
but here is the list of the most significant changes:

Web UI Improvements.
Enhanced OpenSSH compatibility.
Simplified configuration of trusted clusters.
Dynamic (programmatic) configuration of clusters.

The Enterprise Teleport users also receive:

Vastly improved RBAC with more granular access rules.
Authentication against multiple SAML/OIDC providers.

Web UI Improvements
Previous versions of Teleport had the unfortunate limitation of not letting the Web UI
users to connect to OpenSSH servers. The new UI now includes a simple edit box which
gives users familiar syntax: just type user@host in a "connect" field to connect to
any server within a cluster:
OpenSSH Compatibility
With larger organizations adopting Teleport, we have been receiving
numerous requests to make it easier for users to migrate to Teleport from their
existing OpenSSH-based workflows.
Below are some examples:
SSH CLI
Typing tsh ssh can be tiresome and creating a shell alias isn't always an
option, especially if you have a lot of scripts that won't benefit from an
alias. The latest Teleport tsh client can be renamed to ssh (or you can
create a symlink) and its CLI flags become fully compatible with the existing
ssh usage: inside of bash scripts, Ansible scripts, etc.
SSH Agents
At the end of a successful login, tsh login command now sends the SSH
certificate to an active SSH agent. This, again, allows a much easier
usage of ssh (or any other SSH clients) after the login, perhaps by
modifying ~/.ssh/config:
# Instructs ssh client to use 'lab.example.com' Teleport proxy to
# access any servers behind it. The active SSH agent will provide a
# an SSH certificate
Host *.lab.example.com
    Port 3022
    ProxyCommand ssh -p 3023 %[email protected] -s proxy:%h:%p

Needless to say, when tsh logout is executed the keys are removed from the
agent.
Identity Files
Teleport always supported identity files, i.e. the ability to store the
ephemeral private key and a certificate in a file to be used later via -i
flag.
However, the OpenSSH ssh client uses different format for accepting an SSH certificate
via an identity file: it requires the certificate to be placed in a separate
file, so if you have:
$ ssh -i key.pem login@host

You should also have key.pem-cert.pub file in the same directory for this to
work.
To support this workflow, tsh login now supports --out and --format flags.
To generate the required identity files for the cluster controlled by
'lab.example.com' proxy:
# login:
$ tsh login --out=key.pem --format=openssh --proxy=lab.example.com

# use the retrieved certificate:
$ ssh -i key.pem [email protected]

If this behavior is required by default, you can configure ssh to simply
grab the certificate from Teleport's ~/.tsh directory:
# ~/.ssh/config entry to tell 'ssh' to use teleport certificate when
# connecting to any host behind lab.example.com:
Host *.lab.example.com
    Port 3022
    IdentityFile ~/.tsh/keys/lab.example.com/username
    ProxyCommand ssh -i ~/.tsh/keys/lab.example.com/username -p 3023 %[email protected] -s proxy:%h:%p

With these changes, the Teleport user experience becomes almost identical to traditional ssh.
We have also received tremendous amount of interest of
improving the Web client to completely replace PuTTY
for Windows users. Teleport already has a much nicer web-based terminal UI
but additional features like web-based scp and
web-based agent forwarding are also in the works.
Configurable Ciphers
Teleport is based on Google's SSH implementation and we initially assumed
that their choice of ciphers, key exchange and MAC algorithms should work for everybody. However, we found that different organizations may have their own, different standards.
In order to accommodate this, the crypto can now be restricted to the
pre-defined list of ciphers, KEX and MAC algorithms. See the new
configuration
options in Teleport documentation.
Simplified Trusted Clusters.
The Teleport Trusted Clusters feature allows users of one SSH cluster "A" to
connect to another cluster "B" even when "B" is located behind a firewall
without any open TCP ports.
We have seen this feature used in scenarios like:

Connecting to IoT systems when remote SSH connectivity is needed into "field devices".
Managed service providers (MSP) managing someone else's infrastructure
remotely.
Software teams adding Teleport to their products so they can remotely
troubleshoot issues and push releases into end user infrastructure.

As popular as this feature is, it was historically quite difficult to configure.
Teleport 2.3 makes it much easier. Borrowing from the Kubernetes concept of managed
resources,
we have introduced a simple CLI-based CRUD
interface to Teleport internals.
To connect two clusters together, an administrator only needs to:

Create a YAML description (resource) of a cluster to connect to.
Execute tctl create cluster.yaml command.

Of course, the same steps can be executed programmatically via a
management tool like Ansible or Chef.
Enterprise Enhancements
SSO Improvements
Earlier Teleport versions had a single "authentication preference" setting in
the configuration file. Users could select either a SAML (including ADFS) or
OpenID Connect endpoint.
Teleport 2.3 allows many authentication connectors, and even allows mixing different authentication types. Here's an example:

Regular users receive their SSH certificates via Okta SSO.
If something happens to Okta, the SSH
administrators can always SSH into servers using a built-in Teleport user
database via --auth connector switch.
Temporary contractors can authenticate against a different identity provider,
perhaps an auth0 instance fetching credentials from
Github.

This workflow is supported by adding multiple authentication connectors via
the same tctl create resource interface covered above.
Teleport cybersecurity blog posts and tech newsEvery other week we'll send a newsletter with the latest cybersecurity news and Teleport updates.
RBAC Improvements
Perhaps the biggest news is the new RBAC role format which is now officially
supported by Teleport 2.3. Below is the example of a new role format:
kind: role
version: v3
metadata:
  name: admin
spec:
  # SSH options used for user sessions
  options:
    # max_session_ttl defines the TTL (time to live) of SSH certificates
    # issued to the users with this role.
    max_session_ttl: 8h

    # forward_agent controls either users are allowed to use SSH agent forwarding
    forward_agent: true

  # allow section declares a list of resource/verb combinations that are
  # allowed for the users of this role. by default nothing is allowed.
  allow:
    # logins array defines the OS logins a user is allowed to use.
    logins: [root, dba]

    # node labels that a user can connect to. The wildcard ('*') means "any node"
    node_labels:
      '*': '*'

    # see below.
    rules:
    - resources: [role]
      verbs: [list, create, read, update, delete]
    - resources: [auth_connector]
      verbs: [connect, list, create, read, update, delete]
    - resources: [session]
      verbs: [list, read]
    - resources: [trusted_cluster]
      verbs: [connect, list, create, read, update, delete]

  # the deny section uses the identical format as the 'allow' section.
  # the deny rules always override allow rules.
  deny: {}

As you can see, different parts of an SSH cluster now have quite granular
access rights and permissions. A Teleport administrator can remove access to the recorded
sessions, configure SSH options on a per-role basis, map roles between
different clusters for infrastructure co-owned by multiple organizations and
much, much more.
Talk to us!
For more information about Teleport, you can take a look at the
documentation or the
overview. It is open sourced, so
feel free to dig in - issues and/or pull requests are welcome. Also, feel free to
reach out via email if you have additional questions: [email protected].