Skip to main content
Installing Teleport Tooling: An Overview
Installing Teleport Tooling: An Overview

Length: 03:48

Version: 14.x

Installing Teleport

This guide shows you how to install Teleport binaries on your platform, including:

  • teleport
  • tsh
  • tctl
  • tbot

If you are new to Teleport, we recommend following our getting started guide.

For best results, Teleport clients (tsh, tctl, tbot) should be the same major version as the cluster they are connecting to. Teleport servers are compatible with clients that are on the same major version or one major version older. Teleport servers do not support clients that are on a newer major version.

See our Upgrading guide for more information.

Operating system support​

Teleport is officially supported on the platforms listed below. It is worth noting that the open-source community has been successful in building and running Teleport on UNIX variants other than Linux [1].

Operating Systemteleport Daemontctl Admin Tooltsh and Teleport Connect User Clients [2]Web UI (via the browser)tbot Daemon
Linux v2.6.23+ (RHEL/CentOS 7+, Amazon Linux 2+, Amazon Linux 2023+, Ubuntu 16.04+, Debian 9+, SLES 12 SP 5+, and SLES 15 SP 5+) [3]yesyesyesyesyes
macOS v10.13+ (High Sierra)yesyesyesyesyes
Windows 10+ (rev. 1607) [4]nonoyesyesno

[1] Teleport is written in Go and many of these system requirements are due to the requirements of the Go toolchain.

[2] tsh is a Command Line Client (CLI) and Teleport Connect is a Graphical User Interface (GUI) desktop client. See Using Teleport Connect for usage and installation.

[3] Enhanced Session Recording requires Linux kernel v5.8+.

[4] Teleport server does not run on Windows yet, but tsh and Teleport Connect (the Teleport desktop clients) supports most features on Windows 10 and later.

Linux​

All installations include teleport, tsh, tctl, and tbot.

Feature support​

Some Teleport features have additional requirements:

FeatureRequirementDebianUbuntuCentOS/RHELAmazon LinuxSLES
Enhanced Session RecordingKernel v5.8+11, or 10 with backports20.04.2+9+2 (post 11/2021), 202312 SP5, 15 SP5
Automatic Updatessystemd-based9+16.04+7+2, 202312 SP5, 15 SP5
Installation through apt/yum/zypper repossystemd-based9+16.04+7+2, 202312 SP5, 15 SP5
note

apt, yum, and zypper repos don't expose packages for all distribution variants. When following installation instructions, you might need to replace ID with ID_LIKE to install packages of the closest supported distribution.

Currently supported distributions (and ID) are:

  • RHEL >= 7 (rhel)
  • CentOS >= 7 (centos)
  • Debian >= 9 (debian)
  • Ubuntu >= 16.04 (ubuntu)
  • Amazon Linux 2 and 2023 (amzn)
  • SLES >= 12 SP5, >= 15 SP5 (sles)

Installation instructions​

Best practices for production security

When running Teleport in production, you should adhere to the following best practices to avoid security incidents:

  • Avoid using sudo in production environments unless it's necessary.
  • Create new, non-root, users and use test instances for experimenting with Teleport.
  • Run Teleport's services as a non-root user unless required. Only the SSH Service requires root access. Note that you will need root permissions (or the CAP_NET_BIND_SERVICE capability) to make Teleport listen on a port numbered < 1024 (e.g. 443).
  • Follow the principle of least privilege. Don't give users permissive roles when more a restrictive role will do. For example, don't assign users the built-in access,editor roles, which give them permissions to access and edit all cluster resources. Instead, define roles with the minimum required permissions for each user and configure access requests to provide temporary elevated permissions.
  • When you enroll Teleport resources—for example, new databases or applications—you should save the invitation token to a file. If you enter the token directly on the command line, a malicious user could view it by running the history command on a compromised system.

You should note that these practices aren't necessarily reflected in the examples used in documentation. Examples in the documentation are primarily intended for demonstration and for development environments.

Select an edition, then follow the instructions for that edition to install Teleport.

The following command updates the repository for the package manager on the local operating system and installs the provided Teleport version:

$ curl https://cdn.teleport.dev/install-v14.3.33.sh | bash -s 14.3.33

Check the Downloads page for the most up-to-date information.

Docker​

Images​

We provide a pre-built Docker image for every version of Teleport. This section describes the available Docker images.

These images are hosted on Amazon ECR Public.

Image suffixes​

For each of the image names listed in this section, you can specify attributes of the image by appending a suffix to the repository name or tag.

Images with the -distroless suffix within the repository name include only the teleport binary and its runtime dependencies, with no shell or utility applications. An example is public.ecr.aws/gravitational/teleport-distroless for Teleport Community Edition.

Images with the *-distroless-debug suffix within the repository name include a Busybox shell and tool suite in addition to Teleport, and are intended for troubleshooting deployments only. They are not intended for production use. An example is public.ecr.aws/gravitational/teleport-distroless-debug.

You can specify the architecture of an image by appending a suffix to its tag. We support the following architecture suffixes: amd64, arm, and arm64. For example, if you want to pull the ARM64 image for public.ecr.aws/gravitational/teleport, you can use public.ecr.aws/gravitational/teleport:14.3.33-arm64.

*-distroless and *-distroless-debug images support multiple architectures natively, and do not require (or support) image suffixes. You can specify an architecture using the --platform flag of docker pull to pull the arm, arm64 or amd64 version of an image.

Version tags​

Images point to a static version of Teleport. Use the image's tag to specify either:

  • The major, minor, and patch version (e.g., 14.3.33 for the latest version of Teleport Community Edition).
  • The major version only, which implies the latest minor and patch numbers for that major version. For example, 14 implies 14.3.33.
Image nameTroubleshooting Tools?Image base
public.ecr.aws/gravitational/teleport-distroless:14.3.33NoDistroless Debian 12
public.ecr.aws/gravitational/teleport-distroless-debug:14.3.33YesDistroless Debian 12

For testing, we always recommend that you use the latest release version of Teleport, which is currently public.ecr.aws/gravitational/teleport-distroless:14.3.33.

Ubuntu 20.04-based images are available from our Legacy Amazon ECR Public repository. Their use is considered deprecated, and they may be removed in future releases.

Running Teleport on Docker​

When running a container from one of the images listed above, consider the container equivalent to running the teleport binary. The Teleport container requires access to a file system and network ports.

Configuration​

Teleport processes read their configuration from a local file path, which is /etc/teleport.yaml by default. Make sure this file path is mounted to your Teleport container.

Data directory​

All Teleport processes read from and write to a data directory, which by default is /var/lib/teleport. Make sure the data directory is mounted to your Teleport container.

License file​

If your Teleport Enterprise container runs the Auth Service, you will need to give it access to a license file at the path named in the configuration, which is /var/lib/teleport/license.pem by default. Make sure a license exists at this location in the Teleport container's data directory.

Other file paths​

Depending on the configuration settings you assign on your Teleport container, you will need to make sure that any file paths you name are mounted on the container.

For example, if you are running the Teleport Proxy Service on a container, you need to mount the directory containing TLS credentials to your Teleport container, then assign the following fields in the container's configuration file to the appropriate paths:

proxy_service:
  https_keypairs:
  - key_file: /my/path/key.pem
    cert_file: /my/path/cert.pem

See the Teleport Configuration Reference for whether a field you would like to assign requires a file path.

Ports​

A single Teleport process can run multiple services, each of which listens on a specific set of ports depending on your configuration. See our Networking Reference for the ports on your Teleport container to expose.

Extracting certificates from distroless images​

Extracting certificates created with tctl auth sign from a container running a distroless image can be tricky due to the absence of a shell and other OS tools.

Where possible you should log into the Teleport cluster using tsh and use tctl auth sign locally to generate certificates. This way the action will be logged against your Teleport user and be subject to all of the usual Teleport RBAC policies in your cluster.

If this is not possible, use tctl auth sign --tar to collect all the files generated by tctl auth sign into a tar archive, which is streamed directly to stdout. The resulting certificates are never stored on the container filesystem. You can either pipe this output directly to tar, or redirect it to a local file for later use.

For example:

docker exec ${TELEPORT_CONTAINER} \
  tctl auth sign --user alice --format tls -o alice.local --tar | tar xv
x alice.local.crt
x alice.local.key
x alice.local.cas

Example of running a Teleport container​

In this example, we will show you how to run the Teleport Auth and Proxy Services on a local Docker container using Teleport Community Edition.

Since this container uses a self-signed certificate, we do not recommend using this configuration to protect any infrastructure outside your workstation. You can, however, join other local Docker containers to it using the token method.

First, create directories in your home directory to mount to the container. The Teleport container will write its configuration and data to these directories:

$ mkdir -p ~/teleport/config ~/teleport/data

Run teleport configure from the Teleport container to generate a configuration file. This sets the container's name to localhost so your browser can trust the Proxy Service's self-signed TLS certificate:

$ docker run --hostname localhost --rm \
  --entrypoint=/usr/local/bin/teleport \
  public.ecr.aws/gravitational/teleport-distroless:14.3.33 configure --roles=proxy,auth > ~/teleport/config/teleport.yaml

Start Teleport on your container:

$ docker run --hostname localhost --name teleport \
  -v ~/teleport/config:/etc/teleport \
  -v ~/teleport/data:/var/lib/teleport \
  -p 3025:3025 -p 3080:3080 \
  public.ecr.aws/gravitational/teleport-distroless:14.3.33

From there, open another terminal and make sure your Teleport container's web API is functioning as intended:

$ curl --insecure https://localhost:3080/webapi/ping

You should see JSON output similar to the following:

{
  "auth": {
    "type": "local",
    "second_factor": "otp",
    "preferred_local_mfa": "otp",
    "local": {
      "name": ""
    },
    "private_key_policy": "none",
    "device_trust_disabled": true,
    "has_motd": false
  },
  "proxy": {
    "kube": {
      "enabled": true,
      "listen_addr": "0.0.0.0:3080"
    },
    "ssh": {
      "listen_addr": "0.0.0.0:3080",
      "tunnel_listen_addr": "0.0.0.0:3080",
      "web_listen_addr": "0.0.0.0:3080"
    },
    "db": {
      "postgres_listen_addr": "0.0.0.0:3080",
      "mysql_listen_addr": "0.0.0.0:3080"
    },
    "tls_routing_enabled": true
  },
  "server_version": "12.1.5",
  "min_client_version": "11.0.0",
  "cluster_name": "localhost",
  "automatic_upgrades": false
}

We are using the --insecure flag to trust Teleport's self-signed certificate. In production, you will want to provision TLS credentials to the Proxy Service from a trusted CA, e.g., Let's Encrypt.

Amazon EC2​

We provide pre-built amd64 Amazon Linux 2023 based EC2 AMIs with Teleport pre-installed.

These images are primarily intended for deploying a Teleport cluster using our reference Terraform code.

See the AWS Single-Instance Deployment and the Running Teleport Enterprise in High Availability mode on AWS using Terraform guide for detailed usage examples.

In order to use these AMIs outside of the reference Terraform, you can configure the Teleport installation by setting configuration variables in the /etc/teleport.d/conf file on the EC2 instance. See the Starter Cluster Configuration Template for a list of the available configuration options.

The image names all include the build timestamp (shown as $TIMESTAMP in the table below), and are tagged for easier searching.

Image nameEditionFIPS supportAMI TagsOwner Account ID
teleport-oss-14.3.33-$TIMESTAMPOSSNoTeleportVersion: 14.3.33, TeleportEdition: oss, TeleportFipsEnabled: false146628656107
teleport-ent-14.3.33-$TIMESTAMPEnterpriseNoTeleportVersion: 14.3.33, TeleportEdition: ent, TeleportFipsEnabled: false146628656107
teleport-ent-14.3.33-fips-$TIMESTAMPEnterpriseYesTeleportVersion: 14.3.33, TeleportEdition: ent, TeleportFipsEnabled: true146628656107

All images are based on Amazon Linux 2023 and have been hardened using the Amazon EC2 ImageBuilder STIG hardening component.

Teleport AMIs are automatically published to all non-opt-in AWS regions.

Helm​

Set up the Teleport Helm repository.

Allow Helm to install charts that are hosted in the Teleport Helm repository:

$ helm repo add teleport https://charts.releases.teleport.dev

Update the cache of charts from the remote repository so you can upgrade to all available releases:

$ helm repo update

There are two charts available to install. Please see our guide for using each chart.

ChartIncluded ServicesValues Reference
teleport-clusterAuth Service
Proxy Service
Other Teleport services if using a custom configuration		Reference
teleport-kube-agentKubernetes Service
Application Service
Database Service		Reference

macOS​

You can download one of the following .pkg installers for macOS:

LinkBinaries
teleport-14.3.33.pkgteleport
tctl
tsh
tbot
tsh-14.3.33.pkgtsh

You can also fetch an installer via the command line:

$ curl -O https://cdn.teleport.dev/teleport-14.3.33.pkg
# Installs on Macintosh HD
$ sudo installer -pkg teleport-14.3.33.pkg -target /
# Password:
# installer: Package name is teleport-14.3.33
# installer: Upgrading at base path /
# installer: The upgrade was successful.
$ which teleport
# /usr/local/bin/teleport

Windows (tsh client only)​

Most tsh features are supported for Windows 10 1607+. The tsh ssh command can be run under cmd.exe, PowerShell, and Windows Terminal.

To install tsh on Windows, run the following commands in PowerShell (these commands will not work in cmd.exe):

# Set the TLS level to TLS 1.2 (required on Windows Server 2016 and lower)
$ [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
# Get the expected checksum for the Windows tsh package
$ $Resp = Invoke-WebRequest https://cdn.teleport.dev/teleport-v14.3.33-windows-amd64-bin.zip.sha256
# PowerShell will return the binary representation of the response content
# by default, so you need to convert it to a string
$ [System.Text.Encoding]::UTF8.getstring($Resp.Content)
# <checksum> <filename>
$ Invoke-WebRequest -OutFile teleport-v14.3.33-windows-amd64-bin.zip -Uri https://cdn.teleport.dev/teleport-v14.3.33-windows-amd64-bin.zip
$ certUtil -hashfile teleport-v14.3.33-windows-amd64-bin.zip SHA256
# SHA256 hash of teleport-v14.3.33-windows-amd64-bin.zip:
# <checksum>
# CertUtil: -hashfile command completed successfully.

After you have verified that the checksums match, you can extract the archive. The executable will be available at teleport-v14.3.33-windows-amd64-bin\tsh.exe.

$ Expand-Archive teleport-v14.3.33-windows-amd64-bin.zip
$ cd teleport-v14.3.33-windows-amd64-bin
$ .\tsh.exe version
Teleport v14.3.33 git:v14.3.33 go1.21

Make sure to move tsh.exe into your PATH.

note

Do not place tsh.exe in the System32 directory, as this can cause issues when using WinSCP. You should use %SystemRoot% (e.g. C:\Windows) instead, which is already included in %PATH%.

If you do not have administrator rights on the Windows system you're using, you can use %USERPROFILE% (e.g. C:\Users\<username>) instead - but note that you will not be able to run tsh commands globally from the command line unless you are in the same directory as tsh.exe.

Building from source​

Teleport is written in Go, and currently requires go v1.21 or newer. Detailed instructions for building from source are available in the README.

Checksums​

If you want to verify the integrity of a Teleport binary, SHA256 checksums are available for all downloads on our downloads page.

Teleport Checksum

If you download Teleport via an automated system, you can programmatically obtain the checksum by adding .sha256 to the download link. This is the method shown in the installation examples.

$ export version=v14.3.33
# 'darwin' 'linux' or 'windows'
$ export os=linux
# '386' 'arm' on linux or 'amd64' for all distros
$ export arch=amd64
$ curl https://cdn.teleport.dev/teleport-$version-$os-$arch-bin.tar.gz.sha256
# <checksum> <filename>

Uninstalling Teleport​

If you wish to uninstall Teleport at any time, see our documentation on Uninstalling Teleport.

Next steps​

Now that you know how to install Teleport, you can enable access to all of your infrastructure. Get started with: