mirror of
https://github.com/gravitational/teleport
synced 2024-10-19 00:33:50 +00:00
Split up the CLI reference (#30129)
Fixes #29957 Improves the page load performance of our CLI reference documentation by splitting up the long CLI reference page. This also has other benefits, including: - **SEO**: Users don't need to search for the Teleport CLI reference (and don't need to know that this page exists), but can search for a specific tool they want reference docs for. - **In-page search:** Users searching within a specific page will get results for the tool they are researching, not all of Teleport's CLI tools.
This commit is contained in:
Paul Gottschling
GitHub
parent
e2320d7950
commit
191e645011
|
|
@ -3033,7 +3033,7 @@ This is a minor Teleport release with a focus on new features and bug fixes.
|
|||
* Alpha: Enhanced Session Recording lets you know what's really happening during a Teleport Session. [#2948](https://github.com/gravitational/teleport/issues/2948)
|
||||
* Alpha: Workflows API lets admins escalate RBAC roles in response to user requests. [Read the docs](./docs/pages/access-controls/access-requests.mdx). [#3006](https://github.com/gravitational/teleport/issues/3006)
|
||||
* Beta: Teleport provides HA Support using Firestore and Google Cloud Storage using Google Cloud Platform. [Read the docs](./docs/pages/deploy-a-cluster/deployments/gcp.mdx). [#2821](https://github.com/gravitational/teleport/pull/2821)
|
||||
* Remote tctl execution is now possible. [Read the docs](./docs/pages/reference/cli.mdx#tctl). [#1525](https://github.com/gravitational/teleport/issues/1525) [#2991](https://github.com/gravitational/teleport/issues/2991)
|
||||
* Remote tctl execution is now possible. [Read the docs](./docs/pages/reference/cli/tctl.mdx). [#1525](https://github.com/gravitational/teleport/issues/1525) [#2991](https://github.com/gravitational/teleport/issues/2991)
|
||||
|
||||
### Fixes
|
||||
|
||||
|
|
|
|||
|
|
@ -1367,7 +1367,25 @@
|
|||
},
|
||||
{
|
||||
"title": "Command Line",
|
||||
"slug": "/reference/cli/"
|
||||
"slug": "/reference/cli/",
|
||||
"entries": [
|
||||
{
|
||||
"title": "teleport",
|
||||
"slug": "/reference/cli/teleport/"
|
||||
},
|
||||
{
|
||||
"title": "tsh",
|
||||
"slug": "/reference/cli/tsh/"
|
||||
},
|
||||
{
|
||||
"title": "tctl",
|
||||
"slug": "/reference/cli/tctl/"
|
||||
},
|
||||
{
|
||||
"title": "tbot",
|
||||
"slug": "/reference/cli/tbot/"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Metrics",
|
||||
|
|
|
|||
|
|
@ -589,5 +589,5 @@ within your organization's existing messaging and project management solutions.
|
|||
|
||||
`tsh request create` supports flags to control TTLs for the request and
|
||||
elevated access. See the [CLI
|
||||
Reference](../../reference/cli.mdx#tsh-request-create) for more
|
||||
Reference](../../reference/cli/tsh.mdx#tsh-request-create) for more
|
||||
details.
|
||||
|
|
|
|||
|
|
@ -216,5 +216,5 @@ spec:
|
|||
Users can also create Access Requests with the `tsh request create` command.
|
||||
`tsh request create` supports flags to control TTLs for the request and
|
||||
elevated access. See the [CLI
|
||||
Reference](../../reference/cli.mdx#tsh-request-create) for more
|
||||
Reference](../../reference/cli/tsh.mdx#tsh-request-create) for more
|
||||
details.
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Each principle has many "Points of Focus" which will apply differently to differ
|
|||
| CC6.1 - Manages Credentials for Infrastructure and Software | New internal and external infrastructure and software are registered, authorized, and documented prior to being granted access credentials and implemented on the network or access point. Credentials are removed and access is disabled when access is no longer required or the infrastructure and software are no longer in use. | [Invite nodes to your cluster with short lived tokens](../../agents/join-services-to-your-cluster/join-token.mdx) |
|
||||
| CC6.1 - Uses Encryption to Protect Data | The entity uses encryption to supplement other measures used to protect data at rest, when such protections are deemed appropriate based on assessed risk. | Teleport Audit logs can use DynamoDB encryption at rest. |
|
||||
| CC6.1 - Protects Encryption Keys | Processes are in place to protect encryption keys during generation, storage, use, and destruction. | Teleport acts as a Certificate Authority to issue SSH and x509 user certificates that are signed by the CA and are (by default) short-lived. SSH host certificates are also signed by the CA and rotated automatically |
|
||||
| CC6.2 - Controls Access Credentials to Protected Assets | Information asset access credentials are created based on an authorization from the system's asset owner or authorized custodian. | [Request Approval from the command line](../../reference/cli.mdx#tctl-request-approve) <br/><br/> [Build Approval Workflows with Access Requests](../../access-controls/access-requests.mdx) <br/><br/> [Use Plugins to send approvals to tools like Slack or Jira](../../access-controls/access-requests.mdx) |
|
||||
| CC6.2 - Controls Access Credentials to Protected Assets | Information asset access credentials are created based on an authorization from the system's asset owner or authorized custodian. | [Request Approval from the command line](../../reference/cli/tctl.mdx#tctl-request-approve) <br/><br/> [Build Approval Workflows with Access Requests](../../access-controls/access-requests.mdx) <br/><br/> [Use Plugins to send approvals to tools like Slack or Jira](../../access-controls/access-requests.mdx) |
|
||||
| CC6.2 - Removes Access to Protected Assets When Appropriate | Processes are in place to remove credential access when an individual no longer requires such access. | [Teleport issues temporary credentials based on an employees role and are revoked upon job change, termination or end of a maintenance window](../../access-controls/access-requests.mdx) |
|
||||
| CC6.2 - Reviews Appropriateness of Access Credentials | The appropriateness of access credentials is reviewed on a periodic basis for unnecessary and inappropriate individuals with credentials. | Teleport maintains a live list of all nodes within a cluster. This node list can be queried by users (who see a subset they have access to) and administrators any time. |
|
||||
| CC6.3 - Creates or Modifies Access to Protected Information Assets | Processes are in place to create or modify access to protected information assets based on authorization from the asset’s owner. | [Build Approval Workflows with Access Requests](../../access-controls/access-requests.mdx) to get authorization from asset owners. |
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ fallback to a weaker second factor, like OTP, using `tsh mfa add
|
|||
--mfa-mode=otp`.
|
||||
|
||||
See the possible `--mfa-mode` values in the [Teleport CLI
|
||||
Reference](../../reference/cli.mdx#tsh-global-flags) page.
|
||||
Reference](../../reference/cli/tsh.mdx#tsh-global-flags) page.
|
||||
</Admonition>
|
||||
|
||||
## Step 3/3. Log in using WebAuthn
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ $ tctl get --format json users/<Var name="username"/> | jq '{traits: first.spec.
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
The [`tctl sso test`](../../reference/cli.mdx#tctl-sso-test) command can be used to
|
||||
The [`tctl sso test`](../../reference/cli/tctl.mdx#tctl-sso-test) command can be used to
|
||||
debug SSO logins and see exactly which traits are being sent by your SSO
|
||||
provider and how they are being mapped by your Login Rules.
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ To learn more about the Login Rule expression syntax, check out the
|
|||
[Login Rule Reference](./reference.mdx) page.
|
||||
|
||||
Learn about the `tctl login_rule test` command by running the help command or
|
||||
checking the [reference page](../../reference/cli.mdx#tctl-login_rule-test).
|
||||
checking the [reference page](../../reference/cli/tctl.mdx#tctl-login_rule-test).
|
||||
```code
|
||||
$ tctl help login_rule test
|
||||
```
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ command with:
|
|||
Roles are defined in the **Repository roles** section of your organization's
|
||||
settings.
|
||||
|
||||
See [tctl sso configure github](../../reference/cli.mdx#tctl-sso-configure-github)
|
||||
See [tctl sso configure github](../../reference/cli/tctl.mdx#tctl-sso-configure-github)
|
||||
for a full reference of flags for this command:
|
||||
|
||||
```code
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ $ tctl sso configure oidc --name <CONNECTOR-NAME> \
|
|||
Teleport roles.
|
||||
|
||||
For more information on these and all available flags, see the [tctl sso configure
|
||||
oidc](../../reference/cli.mdx#tctl-sso-configure-oidc) section of the Teleport CLI
|
||||
oidc](../../reference/cli/tctl.mdx#tctl-sso-configure-oidc) section of the Teleport CLI
|
||||
Reference page.
|
||||
|
||||
The file created should look like the example below. This connector requests
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ You can also right click on the "View IdP metadata" link and select
|
|||
Define an Okta SAML connector using `tctl`. Update this example command with
|
||||
the path to your metadata file, and edit the `--attributes-to-roles` values for
|
||||
custom group assignment to roles. See [tctl sso configure
|
||||
saml](../../reference/cli.mdx#tctl-sso-configure-saml) for a full reference of
|
||||
saml](../../reference/cli/tctl.mdx#tctl-sso-configure-saml) for a full reference of
|
||||
flags for this command:
|
||||
|
||||
```code
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ Copy the CA pin and assign it to the value of <Var name="ca-pin" />.
|
|||
<Notice type="warning">
|
||||
|
||||
The CA pin becomes invalid if a Teleport administrator performs the CA rotation
|
||||
by executing [`tctl auth rotate`](../../reference/cli.mdx#tctl-auth-rotate).
|
||||
by executing [`tctl auth rotate`](../../reference/cli/tctl.mdx#tctl-auth-rotate).
|
||||
|
||||
</Notice>
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Here is why we recommend Teleport Node service instead of OpenSSH:
|
|||
Just like with OpenSSH, the `node` service provides SSH access to every node with any clients supporting client SSH certificates:
|
||||
|
||||
- [OpenSSH: `ssh`](../server-access/guides/openssh.mdx)
|
||||
- [Teleport CLI client: `tsh ssh`](../reference/cli.mdx#tsh-ssh)
|
||||
- [Teleport CLI client: `tsh ssh`](../reference/cli/tsh.mdx#tsh-ssh)
|
||||
- [Teleport Proxy UI](./proxy.mdx) accessed via a web browser.
|
||||
- Ansible and other SSH compatible clients.
|
||||
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ should be noted that they are not TAR archives and cannot be read using the `tar
|
|||
## Playback
|
||||
|
||||
SSH and Kubernetes sessions can be played in Teleport's Web UI or by using
|
||||
the [`tsh play`](../reference/cli.mdx#tsh-play) command. Desktop session
|
||||
the [`tsh play`](../reference/cli/tsh.mdx#tsh-play) command. Desktop session
|
||||
recordings can only be played back in the Web UI.
|
||||
|
||||
In the Web UI, the session recordings page is populated by querying Teleport's
|
||||
|
|
|
|||
|
|
@ -243,5 +243,5 @@ To remove `tsh` and associated user data see
|
|||
[Uninstalling Teleport](../management/admin/uninstall-teleport.mdx).
|
||||
|
||||
## Further reading
|
||||
- [CLI Reference](../reference/cli.mdx#tsh-puttyconfig).
|
||||
- [CLI Reference](../reference/cli/tsh.mdx#tsh-puttyconfig).
|
||||
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ version of tsh for any actions performed within the app.
|
|||
Teleport Connect makes tsh available to use in your terminal of choice as well. Please note that at
|
||||
the moment tsh and Teleport Connect operate on different sets of profiles, as Teleport Connect sets
|
||||
a custom home location through [the `TELEPORT_HOME` environment
|
||||
variable](../reference/cli.mdx#tsh-environment-variables). For example, logging in to a new cluster
|
||||
variable](../reference/cli/tsh.mdx#tsh-environment-variables). For example, logging in to a new cluster
|
||||
through tsh will not make that cluster show up in Teleport Connect.
|
||||
|
||||
<Tabs>
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ terminal for the CLI reference.
|
|||
## Introduction
|
||||
|
||||
For the impatient, here's an example of how a user would typically use
|
||||
[`tsh`](../reference/cli.mdx#tsh):
|
||||
[`tsh`](../reference/cli/tsh.mdx):
|
||||
|
||||
<ScopedBlock scope={["oss","enterprise"]}>
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ $ tsh logout
|
|||
|
||||
In other words, Teleport was designed to be fully compatible with existing
|
||||
SSH-based workflows and does not require users to learn anything new, other than
|
||||
to call [`tsh login`](../reference/cli.mdx#tsh-login) in the beginning.
|
||||
to call [`tsh login`](../reference/cli/tsh.mdx#tsh-login) in the beginning.
|
||||
|
||||
## Installing tsh
|
||||
|
||||
|
|
@ -132,7 +132,7 @@ $ tsh ssh --proxy=mytenant.teleport.sh --user=joe root@node
|
|||
|
||||
</ScopedBlock>
|
||||
|
||||
[CLI Docs - tsh ssh](../reference/cli.mdx#tsh-ssh)
|
||||
[CLI Docs - tsh ssh](../reference/cli/tsh.mdx#tsh-ssh)
|
||||
|
||||
## Logging in
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ $ tsh login --proxy=mytenant.teleport.sh
|
|||
|
||||
</ScopedBlock>
|
||||
|
||||
[CLI Docs - tsh login](../reference/cli.mdx#tsh-login)
|
||||
[CLI Docs - tsh login](../reference/cli/tsh.mdx#tsh-login)
|
||||
|
||||
| Port | Description |
|
||||
| - | - |
|
||||
|
|
@ -178,7 +178,7 @@ This allows you to authenticate just once, maybe at the beginning of the day. Su
|
|||
type="tip"
|
||||
title="Tip"
|
||||
>
|
||||
It is recommended to always use [`tsh login`](../reference/cli.mdx#tsh-login) before using any other `tsh` commands. This allows users to omit `--proxy` flag in subsequent tsh commands. For example `tsh ssh user@host` will work.
|
||||
It is recommended to always use [`tsh login`](../reference/cli/tsh.mdx#tsh-login) before using any other `tsh` commands. This allows users to omit `--proxy` flag in subsequent tsh commands. For example `tsh ssh user@host` will work.
|
||||
</Admonition>
|
||||
|
||||
A Teleport cluster can be configured for multiple user identity sources. For example, a cluster may have a local user called `admin` while regular users should [authenticate via GitHub](../access-controls/sso/github-sso.mdx). In this case, you have to pass `--auth` flag to `tsh login` to specify which identity storage to use:
|
||||
|
|
@ -231,7 +231,7 @@ $ tsh login --proxy=mytenant.teleport.sh --browser=none
|
|||
In this situation, a link will be printed on the screen. You can copy and paste this link into
|
||||
a browser of your choice to continue the login flow.
|
||||
|
||||
[CLI Docs - tsh login](../reference/cli.mdx#tsh-login)
|
||||
[CLI Docs - tsh login](../reference/cli/tsh.mdx#tsh-login)
|
||||
|
||||
### Inspecting an SSH certificate
|
||||
|
||||
|
|
@ -271,7 +271,7 @@ $ tsh status
|
|||
|
||||
</ScopedBlock>
|
||||
|
||||
[CLI Docs - tsh status](../reference/cli.mdx#tsh-status)
|
||||
[CLI Docs - tsh status](../reference/cli/tsh.mdx#tsh-status)
|
||||
|
||||
### SSH agent support
|
||||
|
||||
|
|
@ -292,7 +292,7 @@ variable to `false` in your shell profile to make this permanent.
|
|||
|
||||
### Identity files
|
||||
|
||||
[`tsh login`](../reference/cli.mdx#tsh-login) can also save the user certificate into a
|
||||
[`tsh login`](../reference/cli/tsh.mdx#tsh-login) can also save the user certificate into a
|
||||
file:
|
||||
|
||||
<ScopedBlock scope={["oss", "enterprise"]}>
|
||||
|
|
@ -389,7 +389,7 @@ $ tctl auth sign --ttl=1h --user=jenkins --out=jenkins.pem
|
|||
|
||||
</ScopedBlock>
|
||||
|
||||
[CLI Docs - tctl auth sign](../reference/cli.mdx#tctl-auth-sign)
|
||||
[CLI Docs - tctl auth sign](../reference/cli/tctl.mdx#tctl-auth-sign)
|
||||
|
||||
Now `jenkins.pem` can be copied to the Jenkins server and passed to the `-i`
|
||||
(identity file) flag of `tsh`.
|
||||
|
|
@ -414,7 +414,7 @@ $ tsh ls
|
|||
# graviton 10.1.0.7:3022 os:osx
|
||||
```
|
||||
|
||||
[CLI Docs - tsh ls](../reference/cli.mdx#tsh-ls)
|
||||
[CLI Docs - tsh ls](../reference/cli/tsh.mdx#tsh-ls)
|
||||
|
||||
`tsh ls` can apply a filter based on the node labels.
|
||||
|
||||
|
|
@ -427,7 +427,7 @@ $ tsh ls os=osx
|
|||
# graviton 33333333-aaaa-1284 10.1.0.7:3022 os:osx
|
||||
```
|
||||
|
||||
[CLI Docs -tsh ls](../reference/cli.mdx#tsh-ls)
|
||||
[CLI Docs -tsh ls](../reference/cli/tsh.mdx#tsh-ls)
|
||||
|
||||
<Details title="Not seeing Nodes?">
|
||||
|
||||
|
|
@ -698,7 +698,7 @@ $ tsh --proxy=mytenant.teleport.sh clusters
|
|||
|
||||
</ScopedBlock>
|
||||
|
||||
[CLI Docs - tsh clusters](../reference/cli.mdx#tsh-clusters)
|
||||
[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:
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ databases.
|
|||
|
||||
A single running `teleport` process can run one or more **Teleport services**,
|
||||
depending on the user's configuration. Read about all subcommands of `teleport`
|
||||
in our [CLI Reference](./reference/cli.mdx#teleport).
|
||||
in our [CLI Reference](./reference/cli/teleport.mdx).
|
||||
|
||||
### Teleport Application Service
|
||||
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ users and permission to manage the passwords in AWS Secrets Manager.
|
|||
|
||||
You can generate and manage the permissions with the [`teleport db configure
|
||||
bootstrap`](../../database-access/reference/cli.mdx#teleport-db-configure-bootstrap)
|
||||
command. For example, the following command would generate and print the
|
||||
IAM policies:
|
||||
command. For example, the following command would generate and print the IAM
|
||||
policies:
|
||||
|
||||
```code
|
||||
$ teleport db configure bootstrap --manual
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ 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](./reference/cli.mdx#tctl-alerts-list).
|
||||
[CLI Reference](./reference/cli/tctl.mdx#tctl-alerts-list).
|
||||
|
||||
## Does Teleport send any data back to the cloud?
|
||||
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ to federate trust across Kubernetes clusters.
|
|||
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">
|
||||
|
||||
When multiple Trusted Clusters are present behind the Teleport Proxy Service, the
|
||||
`kubeconfig` generated by [tsh login](../../reference/cli.mdx#tsh-login) will contain the
|
||||
`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) will contain the
|
||||
Kubernetes API endpoint determined by the `<cluster>` argument to [tsh
|
||||
login](../../reference/cli.mdx#tsh-login).
|
||||
login](../../reference/cli/tsh.mdx#tsh-login).
|
||||
|
||||
For example, consider the following setup:
|
||||
|
||||
|
|
@ -45,9 +45,9 @@ $ tsh --proxy=main.example.com login east
|
|||
<TabItem scope={["cloud","team"]} label="Cloud-Hosted">
|
||||
|
||||
When multiple Trusted Clusters are present behind the Teleport Proxy Service, the
|
||||
`kubeconfig` generated by [tsh login](../../reference/cli.mdx#tsh-login) will contain the
|
||||
`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) will contain the
|
||||
Kubernetes API endpoint determined by the `<cluster>` argument to [tsh
|
||||
login](../../reference/cli.mdx#tsh-login).
|
||||
login](../../reference/cli/tsh.mdx#tsh-login).
|
||||
|
||||
For example, consider the following setup:
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,6 @@ description: Configuration and CLI reference for Teleport Machine ID.
|
|||
- [Configuration](./reference/configuration.mdx)
|
||||
- [GitHub Actions](./reference/github-actions.mdx)
|
||||
- [GitLab CI](./reference/gitlab.mdx)
|
||||
- [CLI](../reference/cli.mdx#tbot)
|
||||
- [CLI](../reference/cli/tbot.mdx)
|
||||
- [Telemetry](./reference/telemetry.mdx)
|
||||
- [V14 Upgrade Guide](./reference/v14-upgrade-guide.mdx)
|
||||
|
|
|
|||
|
|
@ -147,8 +147,9 @@ until existing clients disconnect.
|
|||
|
||||
To upgrade a host to a newer version of Teleport, you must:
|
||||
|
||||
- Replace the Teleport binaries, usually [`teleport`](../../reference/cli.mdx#teleport)
|
||||
and [`tctl`](../../reference/cli.mdx#tctl).
|
||||
- Replace the Teleport binaries, usually
|
||||
[`teleport`](../../reference/cli/teleport.mdx) and
|
||||
[`tctl`](../../reference/cli/tctl.mdx).
|
||||
- Execute `systemctl reload teleport`.
|
||||
|
||||
</Admonition>
|
||||
|
|
@ -182,7 +183,7 @@ $ sudo teleport install systemd \
|
|||
|
||||
In this guide, we showed you how to run `teleport start` as a systemd service.
|
||||
To see all commands that you can run via the `teleport` binary, see the
|
||||
[Teleport CLI Reference](../../reference/cli.mdx#teleport).
|
||||
[Teleport CLI Reference](../../reference/cli/teleport.mdx).
|
||||
|
||||
While we used a minimal configuration in this guide, for a production Teleport
|
||||
cluster, you should consult our
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ $ tctl users rm joe
|
|||
In addition to users, you can use `tctl` to manage roles and other dynamic
|
||||
resources. See our [Teleport Resources Reference](../../reference/resources.mdx).
|
||||
|
||||
For all available `tctl` commands and flags, see our [CLI Reference](../../reference/cli.mdx#tctl).
|
||||
For all available `tctl` commands and flags, see our [CLI Reference](../../reference/cli/tctl.mdx).
|
||||
|
||||
You can also configure Teleport so that users can log in using an SSO provider.
|
||||
For more information, see:
|
||||
|
|
@ -131,7 +131,7 @@ In addition to users, you can use `tctl` to manage roles and other dynamic
|
|||
resources. See our [Teleport Resources Reference](../../reference/resources.mdx).
|
||||
|
||||
For all available `tctl` commands and flags, see our
|
||||
[CLI Reference](../../reference/cli.mdx#tctl).
|
||||
[CLI Reference](../../reference/cli/tctl.mdx).
|
||||
|
||||
You can also configure Teleport so that users can log in using GitHub. For more
|
||||
information, see [GitHub SSO](../../access-controls/sso/github-sso.mdx).
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ spec:
|
|||
|
||||
Since `tctl` works from the local filesystem, you can write commands that apply
|
||||
all configuration documents in a directory tree. See the [CLI
|
||||
reference](../reference/cli.mdx#tctl) for more information on `tctl`.
|
||||
reference](../reference/cli/tctl.mdx) for more information on `tctl`.
|
||||
|
||||
### Teleport Terraform provider
|
||||
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ or in a local filesystem (including NFS).
|
|||
The recorded sessions are stored as raw bytes in the `sessions` directory under
|
||||
`log`. Each session is a protobuf-encoded stream of binary data.
|
||||
|
||||
You can replay recorded sessions using the [`tsh play`](./cli.mdx#tsh-play)
|
||||
You can replay recorded sessions using the [`tsh play`](./cli/tsh.mdx#tsh-play)
|
||||
command or the Web UI.
|
||||
|
||||
For example, replay a session via CLI:
|
||||
|
|
@ -186,8 +186,8 @@ $ tsh play 4c146ec8-eab6-11e6-b1b3-40167e68e931 --format=json
|
|||
Teleport Team and Teleport Enterprise Cloud automatically store recorded
|
||||
sessions.
|
||||
|
||||
You can replay recorded sessions using the [`tsh play`](./cli.mdx#tsh-play) command or the Web
|
||||
UI.
|
||||
You can replay recorded sessions using the [`tsh play`](./cli/tsh.mdx#tsh-play)
|
||||
command or the Web UI.
|
||||
|
||||
For example, replay a session via CLI:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,10 @@ provider via **authentication connectors**.
|
|||
## Local (no authentication connector)
|
||||
|
||||
Local authentication is used to authenticate against a local Teleport user
|
||||
database. This database is managed by the [`tctl users`](./cli.mdx#tctl-users-add)
|
||||
command. Teleport also supports multi-factor authentication (MFA) for the local
|
||||
connector. There are several possible values (types) of MFA:
|
||||
database. This database is managed by the [`tctl
|
||||
users`](./cli/tctl.mdx#tctl-users-add) command. Teleport also supports
|
||||
multi-factor authentication (MFA) for the local connector. There are several
|
||||
possible values (types) of MFA:
|
||||
|
||||
- `otp` is the default. It implements the [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm)
|
||||
standard. You can use [Google Authenticator](https://en.wikipedia.org/wiki/Google_Authenticator), [Authy](https://www.authy.com/) or any other TOTP client.
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
239
docs/pages/reference/cli/tbot.mdx
Normal file
239
docs/pages/reference/cli/tbot.mdx
Normal file
|
|
@ -0,0 +1,239 @@
|
|||
---
|
||||
title: tbot CLI reference
|
||||
description: Comprehensive reference of subcommands, flags, and arguments for the tbot CLI tool.
|
||||
---
|
||||
|
||||
`tbot` is a CLI tool used with **Machine ID** that programatically issues and renews
|
||||
short-lived certificates to any service account (e.g, a CI/CD server).
|
||||
|
||||
The primary commands for `tbot` are as follows:
|
||||
|
||||
| Command | Description |
|
||||
| - | - |
|
||||
| `tbot help` | Outputs guidance for using commands with `tbot`. |
|
||||
| `tbot version` | Outputs the current version of the `tbot` binary. |
|
||||
| `tbot configure` | Outputs a basic Machine ID client configuration file to be adjusted as needed. |
|
||||
| `tbot start` | Starts the Machine ID client `tbot`, fetching and writing certificates to disk at a set interval. |
|
||||
| `tbot init` | Initialize a certificate destination directory for writes from a separate bot user, configuring either file or POSIX ACL permissions. |
|
||||
| `tbot db` | Connects to databases using native clients and queries database information. Functions as a wrapper for `tsh`, and requires `tsh` installation. |
|
||||
| `tbot proxy` | Allows for access to Teleport resources on a cluster using TLS Routing. Functions as a wrapper for `tsh`, and requires `tsh` installation. |
|
||||
|
||||
## tbot start
|
||||
|
||||
Starts the Machine ID client `tbot`, fetching and writing certificates to disk at a set interval.
|
||||
|
||||
### Flags
|
||||
|
||||
| Flag | Description |
|
||||
|----------------------|------------------------------------------------------------------------------------------------|
|
||||
| `-d/--debug` | Enable verbose logging to stderr. |
|
||||
| `-c/--config` | Path to a Machine ID configuration file. |
|
||||
| `-a/--auth-server` | Address of the Teleport Auth Server (on-prem installs) or Teleport Cloud tenant. |
|
||||
| `--token` | A bot join token, if attempting to onboard a new bot; used on first connect. Can also be an absolute path to a file containing the token. |
|
||||
| `--ca-pin` | CA pin to validate the Teleport Auth Server; used on first connect. |
|
||||
| `--data-dir` | Directory to store internal bot data. In production environments access to this directory should be limited only to an isolated linux user as an owner with `0600` permissions. |
|
||||
| `--destination-dir` | Directory to write short-lived machine certificates. |
|
||||
| `--certificate-ttl` | TTL of short-lived machine certificates. |
|
||||
| `--renewal-interval` | Interval at which short-lived certificates are renewed; must be less than the certificate TTL. |
|
||||
| `--join-method` | Method to use to join the cluster. Can be `token` or `iam`. |
|
||||
| `--oneshot` | If set, quit after the first renewal. |
|
||||
|
||||
### Examples
|
||||
<Tabs>
|
||||
<TabItem scope={["cloud", "team"]} label="Cloud-Hosted">
|
||||
|
||||
```code
|
||||
$ tbot start \
|
||||
--data-dir=/var/lib/teleport/bot \
|
||||
--destination-dir=/opt/machine-id \
|
||||
--token=00000000000000000000000000000000 \
|
||||
--join-method=token \
|
||||
--ca-pin=sha256:1111111111111111111111111111111111111111111111111111111111111111 \
|
||||
--auth-server=example.teleport.sh:443
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem scope={["enterprise", "oss"]} label="Self-Hosted">
|
||||
|
||||
```code
|
||||
$ tbot start \
|
||||
--data-dir=/var/lib/teleport/bot \
|
||||
--destination-dir=/opt/machine-id \
|
||||
--token=00000000000000000000000000000000 \
|
||||
--join-method=token \
|
||||
--ca-pin=sha256:1111111111111111111111111111111111111111111111111111111111111111 \
|
||||
--auth-server=auth.example.com:3025
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## tbot init
|
||||
|
||||
Initializes a certificate destination directory for access from a separate bot user. Allows for certificates to be written to disks other than a Machine ID client,
|
||||
configuring either file or POSIX ACL permissions.
|
||||
|
||||
### Flags
|
||||
|
||||
| Flag | Description |
|
||||
|---------------------|--------------------------------------------------------------------------------------------------------------------|
|
||||
| `-d/--debug` | Enable verbose logging to stderr. |
|
||||
| `-c/--config` | Path to a Machine ID configuration file. |
|
||||
| `--destination-dir` | Directory to write short-lived machine certificates to. |
|
||||
| `--owner` | Defines the Linux `user:group` owner of `--destination-dir`. Defaults to the Linux user running `tbot` if unspecified. |
|
||||
| `--bot-user` | Enables POSIX ACLs and defines the Linux user that can read/write short-lived certificates to `--destination-dir`. |
|
||||
| `--reader-user` | Enables POSIX ACLs and defines the Linux user that will read short-lived certificates from `--destination-dir`. |
|
||||
| `--init-dir` | If using a config file and multiple destinations are configured, controls which destination dir to configure. |
|
||||
| `--clean` | If set, remove unexpected files and directories from the destination. |
|
||||
|
||||
### Examples
|
||||
|
||||
**Example using file permissions.**
|
||||
|
||||
The following command highlights how to set permissions with `tbot` through Linux groups, using the user and group `jenkins:jenkins`.
|
||||
If running `tbot` as the Linux user `root`, use the following invocation of
|
||||
`tbot init` to initialize the short-lived certificate directory
|
||||
`/opt/machine-id` with owner `jenkins:jenkins`.
|
||||
|
||||
```code
|
||||
$ tbot init \
|
||||
--destination-dir=/opt/machine-id \
|
||||
--owner=jenkins:jenkins
|
||||
```
|
||||
|
||||
**Example using POSIX ACLs.**
|
||||
|
||||
If running `tbot` as the Linux user `teleport`, use the following invocation of
|
||||
`tbot init` to initialize the short-lived certificate directory
|
||||
`/opt/machine-id` with owner `teleport:teleport` but allow `jenkins` to read
|
||||
from `/opt/machine-id`.
|
||||
|
||||
```code
|
||||
$ tbot init \
|
||||
--destination-dir=/opt/machine-id \
|
||||
--bot-user=teleport \
|
||||
--reader-user=jenkins
|
||||
```
|
||||
|
||||
## tbot db
|
||||
|
||||
Connects to databases using native clients and queries database information. This is best used for testing and validation purposes;
|
||||
most users will likely prefer to connect their own databases to a local proxy using `tbot proxy db`.
|
||||
|
||||
Note that `tsh` must be installed to make use of this command.
|
||||
|
||||
### Flags
|
||||
|
||||
| Flag | Description |
|
||||
|---------------------|----------------------------------------------------------------------------------------------------------|
|
||||
| `-d/--debug` | Enable verbose logging to stderr. |
|
||||
| `-c/--config` | Path to a Machine ID configuration file. Required if not using other required configuration flags. |
|
||||
| `--destination-dir` | Path to the Machine ID destination dir that should be used for authentication. Required. |
|
||||
| `--proxy` | The `host:port` of the Teleport Proxy Service to use to access resources. Required. |
|
||||
| `--cluster` | The name of the cluster on which resources should be accessed. Extracted from the bot identity if unset. |
|
||||
|
||||
All other flags and arguments are passed directly to `tsh db ...`, along
|
||||
with authentication parameters to use the Machine ID identity to skip `tsh`'s
|
||||
login steps.
|
||||
|
||||
Note that certain CLI parameters, for example `--help`, may be captured by
|
||||
`tbot` even if intended to be passed to the wrapped `tsh`. A `--` argument can
|
||||
be used to ensure all following arguments are passed to `tsh` and ignored by
|
||||
`tbot`.
|
||||
|
||||
Additionally, be aware of the following limitations of `tbot db`:
|
||||
- `tbot db connect` requires a `tbot db login` for certain database types,
|
||||
like MySQL, so that additional connection parameters can be written to a
|
||||
local configuration file.
|
||||
- `tbot db env` is not fully supported.
|
||||
|
||||
## tbot proxy
|
||||
|
||||
Allows for access to Teleport resources via a local TLS proxy in TLS Routing mode.
|
||||
The `tbot proxy` command acts as a wrapper for `tsh proxy` to provide local proxy functionality for various protocols.
|
||||
|
||||
Note that `tsh` must be installed to make use of this command.
|
||||
|
||||
### Flags
|
||||
|
||||
| Flag | Description |
|
||||
|---------------------|----------------------------------------------------------------------------------------------------------|
|
||||
| `-d/--debug` | Enable verbose logging to stderr. |
|
||||
| `-c/--config` | Path to a Machine ID configuration file. Required if not using other required configuration flags. |
|
||||
| `--destination-dir` | Path to the Machine ID destination dir that should be used for authentication. Required. |
|
||||
| `--proxy` | The `host:port` of the Teleport Proxy Service through which resources will be accessed. Required. |
|
||||
| `--cluster` | The name of the cluster on which resources should be accessed. Extracted from the bot identity if unset. |
|
||||
|
||||
All other flags and arguments are passed directly to `tsh proxy ...`, along
|
||||
with authentication parameters to use the Machine ID identity to skip `tsh`'s
|
||||
login step.
|
||||
|
||||
Additionally, the following should be noted:
|
||||
|
||||
- Certain CLI parameters, for example `--help`, may be captured by
|
||||
`tbot` even if intended to be passed to the wrapped `tsh`. A `--` argument can
|
||||
be used to ensure all following arguments are passed to `tsh` and ignored by
|
||||
`tbot`
|
||||
- If no configuration file is provided, `tbot` will apply a sample configuration based on provided CLI flags.
|
||||
For this reason, it is recommended that settings are explicitly applied to a configuration file in production.
|
||||
|
||||
### Examples
|
||||
|
||||
**Example using OpenSSH**
|
||||
|
||||
The following command forwards standard input and output over a proxy suitable for use as an OpenSSH `ProxyCommand` for SSH access:
|
||||
|
||||
```code
|
||||
$ tbot proxy --destination-dir=./tbot-user --proxy=proxy.example.com:3080 ssh alice@node:3022
|
||||
```
|
||||
|
||||
In this case:
|
||||
- `alice` is the remote username
|
||||
- `node` is the Teleport Node name
|
||||
- `3022` is the remote SSH port, which is `3022` for Nodes running the Teleport
|
||||
SSH service.
|
||||
|
||||
**Example using Database Access**
|
||||
|
||||
The following example opens a local proxy server to the given database. Your database client
|
||||
must still be configured with client TLS certificates:
|
||||
|
||||
```code
|
||||
$ tbot proxy --destination-dir=./tbot-user --proxy=proxy.example.com:3080 db --port=1234 example
|
||||
```
|
||||
|
||||
In this case:
|
||||
- `example` is the name of the database server as it exists in Teleport
|
||||
- `1234` is an arbitrary port on which to run the proxy
|
||||
|
||||
Though not recommended, to avoid the need for additional client authentication,
|
||||
the `--tunnel` flag may be used to perform authentication at the local proxy
|
||||
rather than within your client:
|
||||
|
||||
```code
|
||||
$ tbot proxy --destination-dir=./tbot-user --proxy=proxy.example.com:3080 db --tunnel --port=1234 example
|
||||
```
|
||||
|
||||
Note that this decreases security:
|
||||
- It allows any user on the system to access the database via `localhost`.
|
||||
- Your connection to the database will be unencrypted until it reaches the
|
||||
`tbot` proxy running on `localhost`.
|
||||
|
||||
Refer to the [database guide](../../machine-id/guides/databases.mdx) for more information on
|
||||
using database proxies.
|
||||
|
||||
### Flags
|
||||
|
||||
| Flag | Description |
|
||||
|----------------------|------------------------------------------------------------------------------------------------|
|
||||
| `-d/--debug` | Enable verbose logging to stderr. |
|
||||
| `-c/--config` | Path to a configuration file. |
|
||||
| `-a/--auth-server` | Address of the Teleport Auth Server (on-prem installs) or Teleport Cloud tenant. |
|
||||
| `--token` | A bot join token, if attempting to onboard a new bot; used on first connect. Can also be an absolute path to a file containing the token. |
|
||||
| `--ca-pin` | CA pin to validate the Teleport Auth Server; used on first connect. |
|
||||
| `--data-dir` | Directory to store internal bot data. In production environments access to this directory should be limited only to an isolated linux user as an owner with `0600` permissions. |
|
||||
| `--destination-dir` | Directory to write short-lived machine certificates. |
|
||||
| `--certificate-ttl` | TTL of short-lived machine certificates. |
|
||||
| `--renewal-interval` | Interval at which short-lived certificates are renewed; must be less than the certificate TTL. |
|
||||
| `--join-method` | Method to use to join the cluster. Can be `token` or `iam`. |
|
||||
| `--oneshot` | If set, quit after the first renewal. |
|
||||
1396
docs/pages/reference/cli/tctl.mdx
Normal file
1396
docs/pages/reference/cli/tctl.mdx
Normal file
File diff suppressed because it is too large
Load diff
114
docs/pages/reference/cli/teleport.mdx
Normal file
114
docs/pages/reference/cli/teleport.mdx
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
title: teleport CLI reference
|
||||
description: Comprehensive reference of subcommands, flags, and arguments for the teleport CLI tool.
|
||||
---
|
||||
|
||||
The CLI tool that supports the Teleport Access Platform is called `teleport`, and allows Teleport services to be managed
|
||||
over the command line:
|
||||
|
||||
- [Auth](../../architecture/authentication.mdx)
|
||||
- [Node/SSH](../../architecture/nodes.mdx)
|
||||
- [Proxy](../../architecture/proxy.mdx)
|
||||
- [App](../../application-access/introduction.mdx)
|
||||
- [Database](../../database-access/introduction.mdx)
|
||||
- [Windows Desktop](../../desktop-access/introduction.mdx)
|
||||
- [Kubernetes](../../kubernetes-access/introduction.mdx)
|
||||
|
||||
The primary commands for the `teleport` CLI are as follows:
|
||||
|
||||
| Command | Description |
|
||||
| - | - |
|
||||
| `teleport help` | Outputs guidance for using Teleport commands. |
|
||||
| `teleport start` | Starts the `teleport` process in the foreground using the current shell session, including any services configured by the [configuration YAML file](../config.mdx). |
|
||||
| `teleport status` | Prints the status of the current active Teleport SSH session. |
|
||||
| `teleport configure` | Generates and writes a [configuration YAML file](../config.mdx) for the Teleport service. This file should be customized in production to suit the needs of your environment, and the default output should only be used when testing. |
|
||||
| `teleport version` | Prints the current release version of the Teleport binary installed on your system. |
|
||||
| `teleport app start` | Starts the Teleport Application Service. |
|
||||
| `teleport db start` | Starts the Teleport Database Service. |
|
||||
| `teleport db configure create` | Generates a configuration YAML file for the Database Service. This file should be customized in production to suit the needs of your environment, and the default output should only be used when testing. |
|
||||
| `teleport db configure bootstrap` | Used to bootstrap a configuration to the Teleport Database Service by reading a provided configuration. |
|
||||
| `teleport db configure aws print-iam` | Generates and outputs current IAM policies for a Teleport-managed database. |
|
||||
| `teleport db configure aws create-iam` | Generates, creates, and attaches desired IAM policies to a Teleport-managed database. |
|
||||
| `teleport install systemd` | Creates a systemd unit file, used to configure and install a `teleport` service daemon. |
|
||||
| `teleport node configure` | Generates a configuration YAML file for a Teleport Node accessed via SSH. This file should be customized in production to suit the needs of your environment, and the default output should only be used when testing. |
|
||||
|
||||
<Notice type="tip">
|
||||
For more information on subcommands when working with the `teleport` cli, use the `--help` option or `teleport <subcommand> --help`.
|
||||
</Notice>
|
||||
|
||||
## teleport start
|
||||
|
||||
The `teleport start` command includes a large number of optional configuration flags.
|
||||
|
||||
While configuration flags for `teleport start` can be used to set parameters for Teleport's configuration,
|
||||
we recommend using a [configuration file](../config.mdx) in production.
|
||||
|
||||
### Flags
|
||||
|
||||
| Name | Default Value(s) | Allowed Value(s) | Description |
|
||||
| - | - | - | - |
|
||||
| `-d, --debug` | none | none | enable verbose logging to stderr |
|
||||
| `--insecure-no-tls` | `false` | `true` or `false` | Tells proxy to not generate default self-signed TLS certificates. This is useful when running Teleport on kubernetes (behind reverse proxy) or behind things like AWS ELBs, GCP LBs or Azure Load Balancers where SSL termination is provided externally. |
|
||||
| `-r, --roles` | `proxy`, `node`, `auth` | **string** comma-separated list of `proxy`, `node`, `auth`, `db`, or `app` | start listed services/roles. These roles are explained in the [Core Concepts](../../core-concepts.mdx) document. |
|
||||
| `--pid-file` | none | **string** filepath | create a PID file at the path |
|
||||
| `--advertise-ip` | none | **string** IP | advertise IP to clients, often used behind NAT |
|
||||
| `-l, --listen-ip` | `0.0.0.0` | [**net. IP**](https://golang.org/pkg/net/#IP) | binds services to IP |
|
||||
| `--auth-server` | none | **string** IP | proxy attempts to connect to a specified auth server instead of local auth, disables `--roles=auth` if set |
|
||||
| `--token` | none | **string** | set invitation token to register with an auth server on start, used once and ignored afterwards. Obtain it by running `tctl nodes add` on the auth server.*We recommend to use tools like `pwgen` to generate sufficiently random tokens of 32+ byte length.* |
|
||||
| `--ca-pin` | none | **string** `sha256:<hash>` | set CA pin to validate the Auth Server. Generated by `tctl status` |
|
||||
| `--nodename` | value returned by the `hostname` command on the machine | **string** | assigns an alternative name for the node which can be used by clients to log in. |
|
||||
| `-c, --config` | `/etc/teleport.yaml` | **string** `.yaml` filepath | starts services with config specified in the YAML file, overrides CLI flags if set |
|
||||
| `--apply-on-startup` | none | **string** `.yaml` filepath | On startup, always apply resources described in the file at the given path. Only supports the following types: `token`. |
|
||||
| `--bootstrap` | none | **string** `.yaml` filepath | bootstrap configured YAML resources {/* TODO link how to configure this file */} |
|
||||
| `--labels` | none | **string** comma-separated list | assigns a set of labels to a node, for example env=dev,app=web. See the explanation of labeling mechanism in the [Labeling Nodes](../../management/admin/labels.mdx) section. |
|
||||
| `--insecure` | none | none | disable certificate validation on Proxy Service, validation still occurs on Auth Service. |
|
||||
| `--fips` | none | none | start Teleport in FedRAMP/FIPS 140-2 mode. |
|
||||
| `--skip-version-check` | `false` | `true` or `false` | Skips version checks between the Auth Server this Teleport instance |
|
||||
| `--diag-addr` | none | none | Enable diagnostic endpoints |
|
||||
| `--permit-user-env` | none | none | flag reads in environment variables from `~/.tsh/environment` when creating a session. |
|
||||
| `--app-name` | none | none | Name of the application to start |
|
||||
| `--app-uri` | none | none | Internal address of the application to proxy |
|
||||
| `--app-public-addr` | none | none | Public address fo the application to proxy |
|
||||
|
||||
### teleport start --roles
|
||||
|
||||
The `--roles` flag when used with `teleport --start` instructs Teleport on which specific Teleport services to start. Below is a more cohesive table of roles and their associated services that `teleport start` supports:
|
||||
|
||||
| Service | Role Name | Description |
|
||||
| - | - | - |
|
||||
| [Node](../../architecture/nodes.mdx) | `node` | Allows SSH connections from authenticated clients. |
|
||||
| [Auth](../../architecture/authentication.mdx) | `auth` | Authenticates and authorizes hosts and users who want access to Teleport-managed resources or information about a cluster. |
|
||||
| [Proxy](../../architecture/proxy.mdx) | `proxy` | The gateway that clients use to connect to the Auth Service or resources managed by Teleport. |
|
||||
| [App](../../application-access/introduction.mdx) | `app` | Provides access to applications. |
|
||||
| [Database](../../database-access/reference.mdx) | `db` | Provides access to databases. |
|
||||
|
||||
<Notice type="tip" scope={["cloud"]}>
|
||||
|
||||
Teleport Cloud manages Teleport instances with the `auth` and `proxy` roles. Use
|
||||
the remaining roles to manage access to specific resources and other Teleport
|
||||
clusters.
|
||||
|
||||
</Notice>
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
# By default without any configuration, teleport starts running as a single-node
|
||||
# cluster. It's the equivalent of running with --roles=node,proxy,auth
|
||||
sudo teleport start
|
||||
|
||||
# Starts a node named 'db' running in strictly SSH mode role, joining the cluster
|
||||
# serviced by the auth server running on 10.1.0.1
|
||||
sudo teleport start --roles=node --auth-server=10.1.0.1 --token=xyz --nodename=db
|
||||
|
||||
# Same as the above, but the node runs with db=master label and can be connected
|
||||
# to using that label in addition to its name.
|
||||
sudo teleport start --roles=node --auth-server=10.1.0.1 --labels=db=master
|
||||
|
||||
# Starts an app server that proxies the application "example-app" running at http://localhost:8080.
|
||||
sudo teleport start --roles=app --token=xyz --auth-server=proxy.example.com:3080 \
|
||||
--app-name="example-app" \
|
||||
--app-uri="http://localhost:8080" \
|
||||
--labels=group=dev
|
||||
```
|
||||
|
||||
1401
docs/pages/reference/cli/tsh.mdx
Normal file
1401
docs/pages/reference/cli/tsh.mdx
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -29,7 +29,7 @@ $ teleport configure -o file
|
|||
|
||||
There are also `configure` commands available for the SSH Service and Database
|
||||
Service. See our documentation on `teleport node configure` and `teleport db
|
||||
configure` in the [Teleport CLI Reference](cli.mdx#teleport).
|
||||
configure` in the [Teleport CLI Reference](cli/teleport.mdx).
|
||||
|
||||
<Notice type="warning">
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ The language also supports the following functions:
|
|||
|
||||
## Resource filtering
|
||||
|
||||
Both the [`tsh`](cli.mdx#tsh) and [`tctl`](cli.mdx#tctl) CLI tools allow you to filter nodes,
|
||||
Both the [`tsh`](cli/tsh.mdx) and [`tctl`](cli/tctl.mdx) CLI tools allow you to filter nodes,
|
||||
applications, databases, and Kubernetes resources using the `--query` flag. The `--query` flag allows you to
|
||||
perform more sophisticated searches using the predicate language.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ $ tctl get cluster_auth_preference
|
|||
|
||||
## List of dynamic resources
|
||||
|
||||
Here's the list of resources currently exposed via [`tctl`](./cli.mdx#tctl):
|
||||
Here's the list of resources currently exposed via [`tctl`](./cli/tctl.mdx):
|
||||
|
||||
| Resource Kind | Description |
|
||||
| - | - |
|
||||
|
|
|
|||
|
|
@ -383,7 +383,7 @@ further Getting Started exercises.
|
|||
|
||||
## Next steps
|
||||
|
||||
- Learn more about Teleport `tsh` through the [reference documentation](../reference/cli.mdx#tsh-ssh).
|
||||
- Learn more about Teleport `tsh` through the [reference documentation](../reference/cli/tsh.mdx#tsh-ssh).
|
||||
- Learn more about [Teleport servers](../architecture/nodes.mdx#connecting-to-nodes)
|
||||
- For a complete list of ports used by Teleport, read the [Networking Guide](../reference/networking.mdx).
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue