Teleport Blog - Teleport 2.3 Release - Easy to use - Sep 19, 2017
Teleport 2.3 Release - Easy to use
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 news
Every 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].
Tags
Teleport Newsletter
Stay up-to-date with the newest Teleport releases by subscribing to our monthly updates.