- Version 15.x
- Version 14.x
- Version 13.x
- Version 12.x
- Older Versions
- Available for:
Teleport has been deployed on server clusters with thousands of hosts at Fortune 500 companies. It has been through several security audits from nationally recognized technology security companies, so we are comfortable with the stability of Teleport from a security perspective.
Yes. All Teleport services support agentless mode, where the service proxies
traffic to an upstream infrastructure resource not available on
With Teleport in agentless mode, you can easily control access to SSH servers, Kubernetes clusters, desktops, databases, and internal applications without running any additional software on your servers. Agentless mode supports session recordings and audit logs for deep understanding into user behavior.
For capabilities such as kernel-level logging and user provisioning, we recommend Teleport as a drop in replacement for OpenSSH. Since Teleport replaces the OpenSSH agent while preserving OpenSSH's functionality, you get more functionality without a net addition of an agent on your system.
Yes, this question comes up often and is related to the previous one. Take a look at Using OpenSSH Guide.
Yes, Teleport supports reverse SSH tunnels out of the box. To configure behind-firewall clusters refer to our Trusted Clusters guide.
Teleport Team, Enterprise, and Enterprise Cloud customers should use the Enterprise release of the
teleport binary for agents. Running the Community Edition binary could result in
incompatibility to these cluster editions for certain features.
To verify you have a Teleport Enterprise release installed run the
command and Enterprise will be in the output.
Teleport Enterprise v14.0.1 go1.21
Teleport Community Edition clusters should use the Teleport Community Edition releases. The
command will only include Teleport in its output for those releases.
Teleport v14.0.1 go1.21
See the Installation guide for details on installing to specific platforms with Enterprise or OSS releases.
Yes. When running a Teleport agent, use the
--auth-server flag to point to the
Proxy Service address (this would be
web_listen_addr in your
file configuration). For more information, see
Adding Nodes to the
Yes, Teleport supports tunnel multiplexing on a single port. Set the
tunnel_listen_addr to use the same port as the
setting in the
proxy_service configuration. Teleport will automatically use
multiplexing with that configuration.
Yes, Teleport supports Headless WebAuthn authentication,
which allows you to perform operations like
tsh ssh or
tsh scp from remote systems where you
are not logged in to Teleport or may not have access to a browser.
Make sure that all Teleport components are at least at version 10.3.0. Older versions
don't support the SFTP protocol, and it's enabled by default in
tsh v11.0.0 and OpenSSH v9.0.
If your host machine is joined to an Active Directory domain, you might find user lookups take a lot longer than you expect. The number of Active Directory accounts that must be scanned to perform a user lookup can cause tsh to hang waiting to get information about the current user. To fix this issue, you can use environment variables to set default account information for your Teleport user. If you are experiencing long lookup times on Windows, do the following:
- Make sure
tshis at least at version 12.2.4.
- Either set the
TELEPORT_USERenvironment variable or set the
--userflag to the name of your Teleport user.
- Either set the
TELEPORT_LOGINenvironment variable or set the
--loginflag to the name of current host user. This setting can be overridden if you open a new SSH session on a machine as a different user.
- Set the
TELEPORT_HOMEenvironment variable to be the home directory of your current host user +
\.tsh. For example, if your home directory is
C:\Users\Me, you'd set
You can set these environment variables globally in Windows so that you don't have to set them every
time you run
Teleport provides four editions:
- Teleport Team
- Teleport Enterprise
- Teleport Enterprise Cloud
- Teleport Community Edition
Here is a detailed breakdown of the differences between Teleport's editions.
|Single Sign-On||GitHub||GitHub, Google Workspace, OIDC, SAML, Teleport||GitHub, Google Workspace, OIDC, SAML, Teleport||GitHub, Teleport|
|Role-Based Access Control||✔||✔||✔||✔|
|Hardware Key Support||✖||✔||✔||✖|
|Agentless Integration with OpenSSH Servers||✔||✔||✔||✔|
|Structured Audit Logs||✔||✔||✔||✔|
|Session Recording with Playback||✔||✔||✔||✔|
|Recording Proxy Mode||✔||✔||✖||✖|
|Enhanced Session Recording||✔||✔||✔||✔|
|PCI DSS Features||Limited||✔||✔||Limited|
|SOC 2 Features||Limited||✔||✔||Limited|
|FIPS-compliant binaries available for FedRAMP High||✖||✔||✖||✖|
|Auth and Proxy Service Management||Self-hosted||Self-hosted||Fully managed||Fully managed|
|Proxy Service domain name||Custom||Custom||A subdomain of ||A subdomain of |
|Version support||All supported releases available to install and download.||All supported releases available to install and download.||Deploys last stable release with 2-3 week lag for stability.||Deploys last stable release with 2-3 week lag for stability.|
|Backend support||Any S3-compatible storage for session records, many managed backends for custom audit log storage.||Any S3-compatible storage for session records, many managed backends for custom audit log storage||All data is stored in DynamoDB and S3 with server-side encryption.||All data is stored in DynamoDB and S3 with server-side encryption.|
|Data storage location||Can store data anywhere in the world, on most managed cloud backends||Can store data anywhere in the world, on most managed cloud backends||Data is stored in ||Data is stored in |
|Hardware Security Module support for encryption at rest||✖||✔||✖||✖|
|Support||Community||24x7 support with premium SLAs and account managers||24x7 support with premium SLAs and account managers||Community|
|Annual or multi-year contracts, volume discounts||✖||✔||✔||✖|
|Anonymized Usage Tracking||Opt-in||✔||✔||✔|
Teleport releases a new major version approximately every 4 months, and provides security-critical support for the current and two previous major versions. With our typical release cadence, we usually support each major version for 12 months.
Here are the major versions of Teleport and their support windows:
|Release||Release Date||EOL||Minimum |
|v14.0||September 20, 2023||September 2024||v13.0.0|
|v13.0||May 8, 2023||May 2024||v12.0.0|
|v12.0||February 6, 2023||February 2024||v11.0.0|
When running multiple
teleport binaries within a cluster, the following rules
- Patch and minor versions are always compatible, for example, any 8.0.1 component will work with any 8.0.3 component and any 8.1.0 component will work with any 8.3.0 component.
- Servers support clients that are 1 major version behind, but do not support
clients that are on a newer major version. For example, an 8.x.x Proxy Service
is compatible with 7.x.x resource services and 7.x.x
tsh, but we don't guarantee that a 9.x.x resource service will work with an 8.x.x Proxy Service. This also means you must not attempt to upgrade from 6.x.x straight to 8.x.x. You must upgrade to 7.x.x first.
- Proxy Services and resource services do not support Auth Services that are on
an older major version, and will fail to connect to older Auth Services by
default. This behavior can be overridden by passing
--skip-version-checkwhen starting Proxy Services and resource services.
Yes. You can copy and paste using a mouse.
Please refer to our Networking guide.
Teleport monitors the inventory of all cluster components and compares their Teleport versions with the latest release on our GitHub page. If a component is not on the latest release, Teleport will create a cluster alert encouraging users to upgrade.
This check is performed against all cluster components, including the Proxy Service and Auth Service, as well as agents running other Teleport Services.
Teleport requires a minimum of TLS version 1.2.
This means that when applications and clients establish or accept TLS connections with Teleport processes, they must use TLS 1.2 or a higher protocol version. Teleport enforces this requirement in all operations that involve TLS connections.
tctl alerts ack command can be used to acknowledge an alert and
temporarily prevent it from being displayed to users. To acknowledge an alert,
you need its ID. You can get a listing of all alerts and their IDs with the
tctl alerts list command.
For detailed information on this family of commands, see the CLI Reference.
The open source edition of Teleport does not send any information to our company, and can be used on servers without internet access.
The commercial editions of Teleport can optionally be configured to send anonymized information, depending on the license purchased. This information contains the following:
- Teleport license identifier;
- anonymized cluster name and Teleport auth server host ID;
- for each Teleport user, the anonymized user name and a per-protocol count of interactions - Teleport logins, SSH and Kubernetes exec sessions, Application access web sessions and TCP connections, SSH port forwards, Kubernetes API requests, SFTP actions.
The anonymization is done by passing names and IDs through HMAC-SHA-256, with a HMAC key that's randomly generated when the Teleport cluster is initialized for the first time and is never shared with us; this makes it infeasible for anyone without access to the cluster to deanonymize the data we store.
The code that aggregates and anonymizes this data can be found in our repository on GitHub.
Reach out to
[email protected] if you have questions about the commercial
editions of Teleport.
When you first start the app, Teleport Connect asks for permission to collect and send telemetry data. This includes tracking events such as:
- Logging in to a cluster
- Starting an SSH, database, or Kubernetes session
- File transfer during an SSH session
- Creating an Access Request
- Reviewing an Access Request
- Assuming an Access Request
On login, we also collect some device-related data:
- Operating system and its version
- App version
- Processor architecture
Additionally, we ask for a job role (answer is optional).
The full list of events and collected data is defined as protocol buffer messages in the Teleport source. We do not track the details of those events but merely that the given event took place. Each event includes the cluster name and user name anonymized with HMAC using the cluster's internal random UUID as the key. It is infeasible to associate this back to a specific cluster or user without access to the cluster's internal datastore.
If you no longer want to send usage data, see disabling telemetry.