Jun 13, 2017
by
Ev Kontsevoy

Today we are officially releasing version
2.2 of Teleport. We’d
like to thank the community and our growing customer base for their valuable
feedback and support of Teleport. We are also excited to publish an updated security
audit of the Teleport code performed by folks at Cure 53.

But first, let’s start with some quick stats on the Teleport Github repository
as of 06/13/2017:

Over 5,000 Github Stars

Over 2,771 commits from 36 contributors

What is Teleport?

Teleport is a modern SSH server designed for teams managing distributed
infrastructure. The most popular Teleport features are:

What’s new in 2.2?

HTTP proxy support

It is now possible to run behind-firewall Teleport clusters that are forced to
tunnel all connections via an HTTP proxy set in http_proxy and https_proxy
environment variables. See more here: #860

The use case for this is when you have a group of servers located in a
locked-down enterprise environments (possibly controlled by enterprise IT)
where all servers are forced to go via an HTTP proxy when talking to the
outside world (public internet). If you need to remotely manage such cluster via SSH,
Teleport proxy (SSH jump host) will now look for xxx_proxy environment
variables and will establish an outgoing SSH tunnel going through HTTP proxy.

ARM

We have been happily running Teleport on our Raspberry Pi test cluster for over
a year now. Due to the popular demand, we have decided to start officially
publishing ARM binaries with our releases and we’re adding ARM platform to the
list of supported platforms for Teleport Enterprise.

For those building Teleport from source, the official way to bake an ARM
executable is to build on ARM. We do not use cross-compiling at the moment, so:

Get yourself an ARM box. Raspberry Pi 3 would do. We like hosted ARM servers
from Scaleway but hear
that folks Packet have
something even beefier.

Client Improvements

For some folks, tsh ssh meant twice as much typing than ssh. Now, if you
rename tsh binary to ssh (or if you make a symlink ssh -> tsh) you can
skip typing tsh and use familiar SSH syntax like ssh [email protected]. This also
makes it easier integrating with Ansible, since you can now easily configure
Ansible for Teleport by setting its
ssh-executable
setting.

Another nice addition is the support for -i flag. This is useful for
authenticating SSH robots who cannot (obviously) answer 2FA challenge or go
via SAML endpoint. First, you can generate an identity file using tctl
tool, and then you can pass it via -i flag to tsh ssh like this:

# do this once on the Teleport auth server:
$ tctl auth sign --user=joe > joe.pem
# now you can use joe.pem to authenticate as joe:
$ tsh -i joe.pem ssh host

Starting with 2.2 tsh now supports per-user environment files, similar to
ssh. If you create an environment file on a server in ~/.tsh/environment
it will be applied to your SSH sessions. The format of that file is the same
as the output of env.

Server Improvements

Teleport 2.2 allows you to restrict ciphers, key exchange algorithms and MACs
to your own subset. Teleport is based on Golang’s implementation of SSH,
which we always felt provided secure defaults, but enterprise Teleport users
needed a way to hand-pick which ciphers are allowed.
With 2.2 this is now possible.

We have also significantly improved interoperability with OpenSSH, including:

New in Enterprise 2.2

Role mapping for Trusted Clusters. For example if you have two organizations,
say “EU” and “US” and you have SSH roles defined inside of each, you can map
users of a role of the EU cluster to another role inside the US cluster and vice versa.
It is possible to say that US-based role “admin” automatically becomes
“guest” if a user connects to the EU cluster. This allows to create flexible
RBAC-driven policies in environments where outsourced IT (or external vendor
support) need to securely access a subset of your infrastructure.

Full Changelog

You can see the full list of changes in the CHANGELOG.
You can also see the list of Github issues
that have been addressed during 2.2 release cycle.

Security Audit

Last year before the release of Teleport 1.0, we hired a well known security
consultancy to audit the Teleport code base so we could be confident calling
Teleport 1.0 a production ready release. While we were incredibly satisfied
with the work, we could not publicly publish the results. When we were
discussing the release of Teleport 2.0, being able to publicly release the
results of the latest security audit was one of the top requirements for the
next audit because we wanted to increase transparency around Teleport security.

We started the engagement with Cure53 in late April as we were preparing the major changes in 2.x series of Teleport.
We worked together to identify and patch all issues as they were found and released
released Teleport 2.0.5 as they
completed the audit. Now with the release of Teleport 2.2.0, which contains all
the security fixes in addition to additional features, we’re also releasing the full report from Cure 53.

With two professional security audits and thousands of OSS adopters performing
their own independent analysis, we continue to be confident in recommending
Teleport for production use.

Upgrading

Teleport 2.2 is meant to be a drop-in replacement for the 2.x series. However, it is always
recommended to make a backup of the cluster state prior to replacing the
teleport binary with a new version. The cluster state is located in
/var/lib/teleport directory for filesystem-based deployments. Users of the etcd backend
should use etcdctl backup command to accomplish this.

More info

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].