Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v15] docs: update tsh client guide for trusted clusters #50338

Merged
merged 2 commits into from
Dec 17, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 3 additions & 59 deletions docs/pages/connect-your-client/tsh.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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

Expand All @@ -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
```
Expand All @@ -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
Expand Down
Loading