title | description | h1 |
---|---|---|
Teleport FAQ |
Frequently Asked Questions About Using Teleport |
Teleport FAQ |
This page includes answers to frequently asked questions about setting up, managing, and using Teleport. If you are new to Teleport, read our Getting Started Guide.
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, Teleport supports reverse SSH tunnels out of the box. To configure behind-firewall clusters, see Configure Trusted Clusters.
Teleport provides two editions:
- Teleport Enterprise
- Teleport Community Edition
Here is a detailed breakdown of the differences between Teleport's editions.
(!docs/pages/includes/edition-comparison.mdx!)
Should we use Teleport Enterprise or Teleport Community Edition for connecting resources to our Teleport cluster?
(!docs/pages/includes/ent-vs-community-faq.mdx!)
Yes. When running a Teleport Agent, use the --auth-server
flag to point to the
Proxy Service address (this would be public_addr
and web_listen_addr
in your
file configuration). For more information, see
Adding Nodes to the
Cluster.
Yes, Teleport supports tunnel multiplexing on a single port. Set the
tunnel_listen_addr
to use the same port as the web_listen_addr
address
setting in the proxy_service
configuration. Teleport will automatically use
multiplexing with that configuration.
Yes. All Teleport services support agentless mode, where the service proxies
traffic to an upstream infrastructure resource not available on localhost
.
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 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.
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:
- Either set the
TELEPORT_USER
environment variable or set the--user
flag to the name of your Teleport user. - Either set the
TELEPORT_LOGIN
environment variable or set the--login
flag 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_HOME
environment variable to be the home directory of your current host user +\.tsh
. For example, if your home directory isC:\Users\Me
, you'd setTELEPORT_HOME
toC:\Users\Me\.tsh
.
You can set these environment variables globally in Windows so that you don't have to set them every
time you run tsh
.
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 tsh version |
---|---|---|---|
v17.0 | November 16, 2024 | November 2025 | v16.0.0 |
v16.0 | June 14, 2024 | June 2025 | v15.0.0 |
v15.0 | January 29, 2024 | January 2025 | v14.0.0 |
(!docs/pages/includes/compatibility.mdx!)
Yes. You can copy and paste using a mouse.
Please refer to our Networking guide.
Teleport offers this feature for the Enterprise (Cloud) and Enterprise (Self-Hosted) versions of Teleport.
A Teleport user's assigned roles are embedded in the client certificate they receive upon logging on. This certificate remains valid and can be used until its expiry, even if the user's role set has changed.
To get a new certificate with the new role set, the user will need to log out and log back in.
Revocation of Teleport access should be done with Teleport's session and identity locks, not by removing roles.
Teleport supports SCIM provisioning for Okta via the hosted Okta integration, available in the Enterprise (Cloud) and Enterprise (Self-Hosted) versions of Teleport.
Refer to the hosted Okta integration guide for details on setting up and configuring SCIM support.
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.
Yes. The 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 Service 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.
For more details, see the Usage Reporting and Billing guide.
Reach out to sales@goteleport.com
if you have questions about the commercial
editions of Teleport.
(!docs/pages/includes/teleport-connect-telemetry.mdx!)
If you no longer want to send usage data, see disabling telemetry.