Teleport 2.2 Released: New Features, Enhancements and Updated Security Audit Report Published.
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:
- Certificate-based SSH: no need to distribute SSH keys.
- Teleport makes behind-firewall / cross-region SSH easy with automatic SSH jump-hosts.
- Strong audit capabilities including session recording & replay.
- Built-in 2nd factor authentication.
- Beautiful Web UI.
- Integration with SAML & OpenID Connect providers like Okta, Active Directory, Auth0, etc (Teleport Enterprise version only)
- SSH role-based access control / RBAC (Teleport Enterprise version only)
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
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
variables and will establish an outgoing SSH tunnel going through HTTP proxy.
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.
- Get Golang 1.8.3 for ARM.
Build as usual:
$ git-clone [email protected]:gravitational/teleport.git $ cd teleport $ make release
For some folks,
tsh sshmeant twice as much typing than
ssh. Now, if you rename
ssh(or if you make a symlink
ssh -> tsh) you can skip typing
tshand 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
-iflag. 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
tctltool, and then you can pass it via
tsh sshlike 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
tshnow supports per-user environment files, similar to
ssh. If you create an environment file on a server in
~/.tsh/environmentit will be applied to your SSH sessions. The format of that file is the same as the output of
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:
- Using the same file format for exporting cluster certificates.
scpbehavior between OpenSSH clients and Teleport servers.
- Compatible keep alive message processing.
New in Enterprise 2.2
Enterprise edition of Teleport also gained a couple new features:
- Full support for SAML 2.0
- 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.
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.
Teleport cybersecurity blog posts and tech news
Every other week we'll send a newsletter with the latest cybersecurity news and Teleport updates.
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
etcdctl backup command to accomplish this.
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].
- Teleport 2.0.5 Security Fixes in this release
- SSH into AWS using Github for RBAC
- Teleport 2.0 Release Information