[v17] docs: update tsh client guide for trusted clusters (#50336)

* docs: update tsh client for trusted clusters * docs: remove extra space in tsh guide
gravitational · Dec 17, 2024 · 3d24cba · 3d24cba
1 parent 6c773b2
commit 3d24cba
Showing 1 changed file with 3 additions and 59 deletions.
diff --git a/docs/pages/connect-your-client/tsh.mdx b/docs/pages/connect-your-client/tsh.mdx
@@ -699,8 +699,9 @@ tunnels from behind-firewall environments into a Teleport Proxy Service you have
 To learn more about setting up a trust relationship between clusters behind firewalls, see
 [Configure Trusted Clusters](../admin-guides/management/admin/trustedclusters.mdx).
 
-<Tabs>
-<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
+<Notice type="note" >
+  Trusted clusters are only available for self-hosted Teleport clusters.
+</Notice>
 
 Assuming the Teleport Proxy Server called `work` is configured with a few trusted
 clusters, you can use the `tsh clusters` command to see a list of all the trusted clusters on the server:
@@ -714,32 +715,10 @@ $ tsh --proxy=work clusters
 # production       offline
 ```
 
-</TabItem>
-<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
-
-Assuming the Teleport Cloud tenant called `mytenant.teleport.sh` is configured with a few trusted
-clusters, a user may use the `tsh clusters` command to see a list of all Trusted Clusters on the server:
-
-```code
-$ tsh --proxy=mytenant.teleport.sh clusters
-
-# Cluster Name     Status
-# ------------     ------
-# staging          online
-# production       offline
-```
-
-</TabItem>
-
-</Tabs>
-
 [CLI Docs - tsh clusters](../reference/cli/tsh.mdx#tsh-clusters)
 
 Now you can use the `--cluster` flag with any `tsh` command. For example, to list SSH nodes that are members of the `production` cluster, simply run:
 
-<Tabs>
-<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
-
 ```code
 $ tsh --proxy=work ls --cluster=production
 
@@ -749,27 +728,8 @@ $ tsh --proxy=work ls --cluster=production
 # db-2          xxxxxxxxx     10.0.20.41:3022    kernel:4.2
 ```
 
-</TabItem>
-<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
-
-```code
-$ tsh --proxy=mytenant.teleport.sh ls --cluster=production
-
-# Node Name     Node ID       Address            Labels
-# ---------     -------       -------            ------
-# db-1          xxxxxxxxx     10.0.20.31:3022    kernel:4.4
-# db-2          xxxxxxxxx     10.0.20.41:3022    kernel:4.2
-```
-
-</TabItem>
-
-</Tabs>
-
 Similarly, if you want to SSH into `db-1` inside the `production` cluster:
 
-<Tabs>
-<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
-
 ```code
 $ tsh --proxy=work ssh --cluster=production db-1
 ```
@@ -779,22 +739,6 @@ firewall without open ports. This works because the `production` cluster
 establishes a reverse SSH tunnel back into the Proxy Service called `work`, and
 this tunnel is used to establish inbound SSH connections.
 
-</TabItem>
-<TabItem scope={["cloud"]} label="Teleport Enterprise Cloud">
-
-```code
-$ tsh --proxy=mytenant.teleport.sh ssh --cluster=production db-1
-```
-
-This is possible even if Nodes in the `production` cluster are located behind a
-firewall without open ports. This works because the `production` cluster
-establishes a reverse SSH tunnel back into your Teleport Cloud tenant's Proxy
-Service, and this tunnel is used to establish inbound SSH connections.
-
-</TabItem>
-
-</Tabs>
-
 ## X11 forwarding
 
 In order to run graphical programs within an SSH session, such as an IDE like