mirror of
https://github.com/gravitational/teleport
synced 2024-10-19 00:33:50 +00:00
[v6.1] Editorial Pass/Review - Home (#6544)
* docs: correct footnote * docs: consistent 2fa * docs: consistent sentence header casing * docs: port tics * docs: correct proper noun * docs: slightly improve prereqs * docs: reword limitations * docs: correct wording, typos * docs: improve getting started page * docs: improve user manual * docs: casing in adopters page * docs: oxford commas * docs: improved faq * docs: tsh in tic marks * docs: admin and prod guide
This commit is contained in:
inertial-frame
Alexander Klizhentas
parent
fbc2e4eafb
commit
a67b522a26
24
CHANGELOG.md
24
CHANGELOG.md
|
|
@ -512,7 +512,7 @@ This addition to Teleport helps customers obtain AC-10 control. We now provide t
|
|||
|
||||
###### `max_connections`
|
||||
|
||||
This value is the total number of concurrent sessions within a cluster to nodes running Teleport. This value is applied at a per user level. If you set `max_connections` to 1, a `tsh` user would only be able to `tsh ssh` into one node at a time.
|
||||
This value is the total number of concurrent sessions within a cluster to nodes running Teleport. This value is applied at a per user level. If you set `max_connections` to `1`, a `tsh` user would only be able to `tsh ssh` into one node at a time.
|
||||
|
||||
###### `max_sessions` per connection
|
||||
|
||||
|
|
@ -860,7 +860,7 @@ This release of Teleport contains bug fixes and improvements.
|
|||
|
||||
This release of Teleport contains bug fixes and minor usability improvements.
|
||||
|
||||
* New build command for client-only (tsh) .pkg builds. [#3159](https://github.com/gravitational/teleport/pull/3159)
|
||||
* New build command for client-only (`tsh`) .pkg builds. [#3159](https://github.com/gravitational/teleport/pull/3159)
|
||||
* Added support for etcd password auth. [#3234](https://github.com/gravitational/teleport/pull/3234)
|
||||
* Added third-party s3 support. [#3234](https://github.com/gravitational/teleport/pull/3234)
|
||||
* Fixed an issue where access-request event system fails when cache is enabled. [#3223](https://github.com/gravitational/teleport/pull/3223)
|
||||
|
|
@ -987,7 +987,7 @@ This is a major Teleport release with a focus on stability and bug fixes.
|
|||
* Support use of a path for `auth_token` in `teleport.yaml`. [#2515](https://github.com/gravitational/teleport/issues/2515)
|
||||
* Implement ProxyJump compatibility. [#2543](https://github.com/gravitational/teleport/issues/2543)
|
||||
* Audit logs should show roles. [#2823](https://github.com/gravitational/teleport/issues/2823)
|
||||
* Allow tsh to go background and without executing remote command. [#2297](https://github.com/gravitational/teleport/issues/2297)
|
||||
* Allow `tsh` to go background and without executing remote command. [#2297](https://github.com/gravitational/teleport/issues/2297)
|
||||
* Provide a high level tool to backup and restore the cluster state. [#2480](https://github.com/gravitational/teleport/issues/2480)
|
||||
* Investigate nodes using stale list when connecting to proxies (discovery protocol). [#2832](https://github.com/gravitational/teleport/issues/2832)
|
||||
|
||||
|
|
@ -995,7 +995,7 @@ This is a major Teleport release with a focus on stability and bug fixes.
|
|||
|
||||
* Proxy can hang due to invalid OIDC connector. [#2690](https://github.com/gravitational/teleport/issues/2690)
|
||||
* Proper `-D` flag parsing. [#2663](https://github.com/gravitational/teleport/issues/2663)
|
||||
* tsh status does not show correct cluster name. [#2671](https://github.com/gravitational/teleport/issues/2671)
|
||||
* `tsh` status does not show correct cluster name. [#2671](https://github.com/gravitational/teleport/issues/2671)
|
||||
* Teleport truncates MOTD with PAM. [#2477](https://github.com/gravitational/teleport/issues/2477)
|
||||
* Miscellaneous fixes around error handling and reporting.
|
||||
|
||||
|
|
@ -1063,7 +1063,7 @@ This release of Teleport contains two bug fixes.
|
|||
|
||||
### Description
|
||||
|
||||
* Fixed issue where new versions of tsh could not connect to older clusters. [#2969](https://github.com/gravitational/teleport/pull/2969)
|
||||
* Fixed issue where new versions of `tsh` could not connect to older clusters. [#2969](https://github.com/gravitational/teleport/pull/2969)
|
||||
* Fixed trait encoding to be more robust. [#2970](https://github.com/gravitational/teleport/pull/2970)
|
||||
|
||||
## 4.0.6
|
||||
|
|
@ -1097,7 +1097,7 @@ This release of Teleport contains multiple bug fixes.
|
|||
|
||||
* Fixed issue that caused processes to be spawned with an incorrect GID. [#2791](https://github.com/gravitational/teleport/pull/2791)
|
||||
* Fixed host certificate principal generation to only include hosts or IP addresses. [#2790](https://github.com/gravitational/teleport/pull/2790)
|
||||
* Fixed issue preventing tsh 4.0 from connection to 3.2 clusters. [#2784](https://github.com/gravitational/teleport/pull/2784)
|
||||
* Fixed issue preventing `tsh` 4.0 from connection to 3.2 clusters. [#2784](https://github.com/gravitational/teleport/pull/2784)
|
||||
|
||||
## 4.0.0
|
||||
|
||||
|
|
@ -1168,7 +1168,7 @@ This release of Teleport contains a bug fix.
|
|||
|
||||
This release of Teleport contains two bug fixes.
|
||||
|
||||
* Fixed issue where new versions of tsh could not connect to older clusters. [#2969](https://github.com/gravitational/teleport/pull/2969)
|
||||
* Fixed issue where new versions of `tsh` could not connect to older clusters. [#2969](https://github.com/gravitational/teleport/pull/2969)
|
||||
* Fixed trait encoding to be more robust. [#2970](https://github.com/gravitational/teleport/pull/2970)
|
||||
|
||||
## 3.2.9
|
||||
|
|
@ -1198,7 +1198,7 @@ This release of Teleport contains a new feature.
|
|||
|
||||
#### Changes
|
||||
|
||||
* Added `--bind-addr` to force tsh to bind to a specific port during SSO login. [#2620](https://github.com/gravitational/teleport/issues/2620)
|
||||
* Added `--bind-addr` to force `tsh` to bind to a specific port during SSO login. [#2620](https://github.com/gravitational/teleport/issues/2620)
|
||||
|
||||
## 3.2
|
||||
|
||||
|
|
@ -1216,7 +1216,7 @@ This release of Teleport contains a bug fix.
|
|||
|
||||
This release of Teleport contains two bug fixes.
|
||||
|
||||
* Fixed issue where new versions of tsh could not connect to older clusters. [#2969](https://github.com/gravitational/teleport/pull/2969)
|
||||
* Fixed issue where new versions of `tsh` could not connect to older clusters. [#2969](https://github.com/gravitational/teleport/pull/2969)
|
||||
* Fixed trait encoding to be more robust. [#2970](https://github.com/gravitational/teleport/pull/2970)
|
||||
|
||||
## 3.1.11
|
||||
|
|
@ -1935,7 +1935,7 @@ This release focus was to increase Teleport user experience in the following are
|
|||
|
||||
* Proper handling of `ENV_SUPATH` from login.defs [#1004](https://github.com/gravitational/teleport/pull/1004)
|
||||
* Reverse tunnels would periodically lose connectivity. [#1156](https://github.com/gravitational/teleport/issues/1156)
|
||||
* tsh now stores user identities in a format compatible with OpenSSH. [1171](https://github.com/gravitational/teleport/issues/1171).
|
||||
* `tsh` now stores user identities in a format compatible with OpenSSH. [1171](https://github.com/gravitational/teleport/issues/1171).
|
||||
|
||||
## 2.2.7
|
||||
|
||||
|
|
@ -2127,7 +2127,7 @@ This release includes several major new features and it's recommended for produc
|
|||
### Features
|
||||
|
||||
* Support for hardware U2F keys for 2nd factor authentication.
|
||||
* CLI client profiles: tsh can now remember its --proxy setting.
|
||||
* CLI client profiles: `tsh` can now remember its --proxy setting.
|
||||
* tctl auth sign command to allow administrators to generate user session keys
|
||||
* Web UI is now served directly from the executable. There is no more need for web
|
||||
assets in `/usr/local/share/teleport`
|
||||
|
|
@ -2173,7 +2173,7 @@ certificates did not work correctly in this release due to #529
|
|||
## 1.0.4
|
||||
|
||||
This release only includes the addition of the ability to specify non-standard
|
||||
HTTPS port for Teleport proxy for tsh --proxy flag.
|
||||
HTTPS port for Teleport proxy for `tsh --proxy` flag.
|
||||
|
||||
## 1.0.3
|
||||
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ spec:
|
|||
**Export access-plugin cert**
|
||||
|
||||
Teleport Plugin uses the `access-plugin` role and user to perform the approval.
|
||||
We export the identify files, using tctl auth sign.
|
||||
We export the identify files, using `tctl auth sign`.
|
||||
|
||||
```bash
|
||||
$ tctl auth sign --format=tls --user=access-plugin --out=auth --ttl=720h
|
||||
|
|
@ -149,7 +149,7 @@ Teleport will generate `auth.crt`, `auth.key`, and `auth.cas` - a certificate, a
|
|||
$ teleport-mattermost configure > /etc/teleport-mattermost.toml
|
||||
```
|
||||
|
||||
Update the config with Teleport address, Mattermost URL and a bot token.
|
||||
Update the config with Teleport address, Mattermost URL, and a bot token.
|
||||
|
||||
```toml
|
||||
# example Mattermost configuration TOML file
|
||||
|
|
@ -269,8 +269,7 @@ Bob can also assume granted access request roles using Web UI:
|
|||
|
||||
**Cert errors**
|
||||
|
||||
You may be getting certificate errors if Teleport's auth server is missing
|
||||
address in the server certificate:
|
||||
You may be getting certificate errors if Teleport's auth server is missing an address in the server certificate:
|
||||
|
||||
```bash
|
||||
authentication handshake failed: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
|
||||
|
|
@ -280,7 +279,7 @@ authentication handshake failed: x509: cannot validate certificate for 127.0.0.1
|
|||
x509: certificate is valid for,*.teleport.cluster.local, teleport.cluster.local, not example.com
|
||||
```
|
||||
|
||||
To fix the problem, update the auth service with public address and restart Teleport:
|
||||
To fix the problem, update the auth service with a public address, and restart Teleport:
|
||||
|
||||
```yaml
|
||||
auth_service:
|
||||
|
|
|
|||
|
|
@ -130,13 +130,14 @@ even when logging into `dev1.example.com`.
|
|||
|
||||
## Limitations
|
||||
|
||||
There are several limitations for this feature:
|
||||
- U2F devices are currently not supported in `tsh` on Windows.
|
||||
Current limitations for this feature are:
|
||||
|
||||
- U2F devices aren't currently supported in `tsh` on Windows.
|
||||
- Only `tsh ssh` supports per-session U2F authentication for SSH (OpenSSH `ssh`
|
||||
does not).
|
||||
- Only `kubectl` supports per-session U2F authentication for Kubernetes.
|
||||
- Database and Application access clients do not support per-session U2F
|
||||
- Database and Application access clients don't support per-session U2F
|
||||
authentication yet, although cluster and role configuration applies to them.
|
||||
If you enable per-session U2F checks cluster-wide, you will not be able to
|
||||
use Database or Application access. We are working on integrating per-session
|
||||
use Database or Application access. We're working on integrating per-session
|
||||
U2F checks for these clients.
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ spec:
|
|||
Any role becomes a template once it starts using template variables.
|
||||
Just like roles, role templates are a valid YAML and validate both the structure and types.
|
||||
|
||||
Role template `devs` is using `internal.` notation referring to local user's
|
||||
Role template `devs` is using `internal` notation referring to local user's
|
||||
traits `logins` and `kubernetes_groups`.
|
||||
|
||||
Use `tctl` to create a role template:
|
||||
|
|
@ -261,7 +261,7 @@ groups: ["admins", "devs"]
|
|||
access: {"env": ["prod", "staging"]}
|
||||
```
|
||||
|
||||
Let's see how these variables a role template `interpolation`:
|
||||
Let's see how these variables are used with role template `interpolation`:
|
||||
|
||||
```yaml
|
||||
kind: role
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ document will be referring to:
|
|||
| Node | Synonym to "server" or "computer", something one can "SSH to". A node must be running the [`teleport`](cli-docs.mdx#teleport) daemon with "node" role/service turned on. |
|
||||
| Certificate Authority (CA) | A pair of public/private keys Teleport uses to manage access. A CA can sign a public key of a user or node, establishing their cluster membership. |
|
||||
| Teleport Cluster | A Teleport Auth Service contains two CAs. One is used to sign user keys and the other signs node keys. A collection of nodes connected to the same CA is called a "cluster". |
|
||||
| Cluster Name | Every Teleport cluster must have a name. If a name is not supplied via `teleport.yaml` configuration file, a GUID will be generated.**IMPORTANT:** renaming a cluster invalidates its keys and all certificates it had created. |
|
||||
| Trusted Cluster | Teleport Auth Service can allow 3rd party users or nodes to connect if their public keys are signed by a trusted CA. A "trusted cluster" is a pair of public keys of the trusted CA. It can be configured via `teleport.yaml` file. |
|
||||
| Cluster Name | Every Teleport cluster must have a name. If a name is not supplied via `teleport.yaml` configuration file, a GUID will be generated. **IMPORTANT:** renaming a cluster invalidates its keys and all certificates it had created. |
|
||||
| Trusted Cluster | Teleport Auth Service can allow 3rd party users or nodes to connect if their public keys are signed by a trusted CA. A *trusted cluster* is a pair of public keys of the trusted CA. It can be configured via `teleport.yaml` file. |
|
||||
|
||||
## Teleport Daemon
|
||||
|
||||
|
|
@ -74,8 +74,8 @@ WantedBy=multi-user.target
|
|||
|
||||
### Graceful Restarts
|
||||
|
||||
If using the systemd service unit file above, executing `systemctl reload
|
||||
teleport` will perform a graceful restart, i.e.the Teleport daemon will fork a
|
||||
If using the `systemd` service unit file above, executing `systemctl reload
|
||||
teleport` will perform a graceful restart, i.e. the Teleport daemon will fork a
|
||||
new process to handle new incoming requests, leaving the old daemon process
|
||||
running until existing clients disconnect.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ h1: Teleport Adopters and Use-Cases
|
|||
## Who is using Teleport?
|
||||
|
||||
Whether you are using Teleport OSS, Enteprise or Cloud, tell us about your use-case.
|
||||
Just click "Improve the docs" and send us a PR.
|
||||
Just click "Improve the docs" below and send us a PR.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
|
|
@ -28,19 +28,19 @@ Just click "Improve the docs" and send us a PR.
|
|||
<tr>
|
||||
<td>Auth0</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/auth0/">case study</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/auth0/">Case study</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Elastic</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/elastic-testimonial/">testimonial</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/elastic-testimonial/">Testimonial</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>VMware</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/vmware-testimonial/">testimonial</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/vmware-testimonial/">Testimonial</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -58,7 +58,7 @@ Just click "Improve the docs" and send us a PR.
|
|||
<tr>
|
||||
<td>ECMWF</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/ecmwf/">case study</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/ecmwf/">Case study</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -88,7 +88,7 @@ Just click "Improve the docs" and send us a PR.
|
|||
<tr>
|
||||
<td>ExtraHop</td>
|
||||
<td>Infosec</td>
|
||||
<td><a href="https://goteleport.com/case-study/extrahop/">case study</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/extrahop/">Case study</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -100,7 +100,7 @@ Just click "Improve the docs" and send us a PR.
|
|||
<tr>
|
||||
<td>GitLab</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/11568#note_451982812">team review</a></td>
|
||||
<td><a href="https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/11568#note_451982812">Team review</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
@ -112,37 +112,37 @@ Just click "Improve the docs" and send us a PR.
|
|||
<tr>
|
||||
<td>Gladly</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/gladly/">case study</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/gladly/">Case study</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>VerticalChange</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/verticalchange-testimonial/">testimonial</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/verticalchange-testimonial/">Testimonial</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Shockbyte</td>
|
||||
<td>Technology</td>
|
||||
<td><a href="https://goteleport.com/case-study/shockbyte-testimonial/">testimonial</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/shockbyte-testimonial/">Testimonial</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Lacework</td>
|
||||
<td>Infosec</td>
|
||||
<td><a href="https://goteleport.com/case-study/lacework-testimonial/">testimonial</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/lacework-testimonial/">Testimonial</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Glu Mobile</td>
|
||||
<td>Gaming</td>
|
||||
<td><a href="https://goteleport.com/case-study/glumobile-testimonial/">testimonial</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/glumobile-testimonial/">Testimonial</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Decisiv</td>
|
||||
<td>Transportation</td>
|
||||
<td><a href="https://goteleport.com/case-study/decisiv/">case study</a></td>
|
||||
<td><a href="https://goteleport.com/case-study/decisiv/">Case study</a></td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ section of the Admin Manual.
|
|||
### Can individual nodes create reverse tunnels to a proxy server without creating a new cluster?
|
||||
|
||||
This has been a long standing [request](https://github.com/gravitational/teleport/issues/803) of Teleport and
|
||||
it has been fixed with Teleport 4.0. Once you've upgraded your Teleport Cluster, change the node config
|
||||
it has been fixed with Teleport 4.0. Once you've upgraded your Teleport Cluster, change the node config
|
||||
option `--auth-server` to point to web proxy address (this would be `public_addr` and `web_listen_addr`
|
||||
in file configuration). As defined in [Adding a node located behind NAT - Teleport Node Tunneling](admin-guide.mdx#adding-a-node-located-behind-nat)
|
||||
|
||||
|
|
@ -76,12 +76,15 @@ We recommend that the Auth Server should be upgraded first, and proxy is bumped
|
|||
|
||||
### Does Web UI support copy and paste?
|
||||
|
||||
Yes. You can copy\&paste using the mouse. For working with a keyboard, Teleport employs
|
||||
`tmux`-like "prefix" mode. To enter prefix mode, press `Ctrl+A`.
|
||||
Yes. You can copy-and-paste using a mouse. If you prefer a keyboard, Teleport employs
|
||||
`tmux`-like "prefix" mode. To enter prefix mode, use the `Ctrl`+`A` keyboard shortcut.
|
||||
|
||||
While in prefix mode, you can press `Ctrl+V` to paste, or enter text selection
|
||||
mode by pressing `[`. When in text selection mode, move around using `hjkl`, select
|
||||
text by toggling `space` and copy it via `Ctrl+C`.
|
||||
While in prefix mode, you can press `Ctrl`+`V` to paste, or enter text selection
|
||||
mode by pressing `[`. When in text selection mode:
|
||||
|
||||
- Move around using the keys `h`,`j`,`k`, and `l`.
|
||||
- Select text by toggling `space`.
|
||||
- And, copy it via `Ctrl`+`C`.
|
||||
|
||||
### What TCP ports does Teleport use?
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,9 @@ Teleport on Linux machines.
|
|||
### Prerequisites
|
||||
|
||||
- A Linux machine with ports `3023`, `3024`, `3025` and `443` open.
|
||||
- A domain name.
|
||||
- A registered domain name.
|
||||
- A two-factor authenticator app.
|
||||
- An SSH client like OpenSSH.
|
||||
- Around 20 minutes to complete; half of this may be waiting for DNS propagation.
|
||||
|
||||
### Follow along with our video guide
|
||||
|
|
@ -23,7 +25,7 @@ Teleport on Linux machines.
|
|||
allowFullScreen
|
||||
/>
|
||||
|
||||
## Step 1: Install Teleport on a Linux Host
|
||||
## Step 1: Install Teleport on a Linux host
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Amazon Linux 2/RHEL (RPM)">
|
||||
|
|
@ -80,14 +82,15 @@ Take a look at the [Installation Guide](installation.mdx) for more options.
|
|||
|
||||
Generate a configuration file for Teleport using `teleport configure`.
|
||||
|
||||
Acme turns on automatic TLS certificates from [Letsencrypt](https://letsencrypt.org).
|
||||
Acme turns on automatic TLS certificates from [Let's Encrypt](https://letsencrypt.org).
|
||||
|
||||
Set up email to receive updates from Let's Encrypt, and use a valid DNS name for a cluster name.
|
||||
|
||||
```bash
|
||||
sudo teleport configure --acme --acme-email=your-email@example.com --cluster-name=tele.example.com -o file
|
||||
```
|
||||
|
||||
## Step 1c: Configure Domain Name and obtain TLS certificates using Let's Encrypt
|
||||
## Step 1c: Configure domain name and obtain TLS certificates using Let's Encrypt
|
||||
|
||||
Teleport requires a secure public endpoint for the Teleport UI and for end users to connect to.
|
||||
To get started setup two `A` records for `tele.example.com` and `*.tele.example.com`
|
||||
|
|
@ -110,10 +113,10 @@ Start Teleport:
|
|||
sudo teleport start
|
||||
```
|
||||
|
||||
You can access Teleport's Web UI on port 443.
|
||||
You can access Teleport's Web UI on port `443`.
|
||||
Replace `tele.example.com` with your domain: `https://tele.example.com/`
|
||||
|
||||
## Step 2: Create a Teleport user and set up 2-factor authentication
|
||||
## Step 2: Create a Teleport user and set up two-factor authentication
|
||||
|
||||
In this example, we'll create a new Teleport user `teleport-admin` which is allowed to log into
|
||||
SSH hosts as any of the principals `root`, `ubuntu` or `ec2-user`.
|
||||
|
|
@ -123,11 +126,11 @@ SSH hosts as any of the principals `root`, `ubuntu` or `ec2-user`.
|
|||
sudo tctl users add teleport-admin --roles=editor,access --logins=root,ubuntu,ec2-user
|
||||
```
|
||||
|
||||
Teleport will always enforce the use of 2-factor authentication by default. It supports one-time
|
||||
Teleport will always enforce the use of two-factor authentication by default. It supports one-time
|
||||
passwords (OTP) and hardware tokens (U2F). This quick start will use OTP - you'll need an OTP-compatible
|
||||
app which can scan a QR code.
|
||||
|
||||
Here's a selection of compatible Two-Factor authentication apps:
|
||||
Here's a selection of compatible two-factor authentication apps:
|
||||
|
||||
- [Authy](https://authy.com/download/)
|
||||
- [Google Authenticator](https://www.google.com/landing/2step/)
|
||||
|
|
@ -153,7 +156,7 @@ Here's a selection of compatible Two-Factor authentication apps:
|
|||
|
||||
<Tabs>
|
||||
<TabItem label="Mac">
|
||||
[Download MacOS .pkg installer](https://goteleport.com/teleport/download?os=macos) (tsh client only, signed) file, double-click to run the installer.
|
||||
[Download MacOS .pkg installer](https://goteleport.com/teleport/download?os=macos) (`tsh` client only, signed) file, double-click to run the installer.
|
||||
</TabItem>
|
||||
|
||||
<TabItem label="Mac - Homebrew">
|
||||
|
|
@ -193,7 +196,7 @@ Here's a selection of compatible Two-Factor authentication apps:
|
|||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Step 3: Log in using `tsh`
|
||||
## Step 3: Log in using tsh
|
||||
|
||||
`tsh` is our client tool. It helps you log into Teleport clusters and obtain short-lived credentials. It can also be used to
|
||||
list servers, applications and Kubernetes clusters registered with Teleport.
|
||||
|
|
@ -205,7 +208,11 @@ Login to receive short-lived certificates from Teleport:
|
|||
tsh login --proxy=teleport.example.com:443 --user=teleport-admin
|
||||
```
|
||||
|
||||
## Step 4: Have Fun with Teleport!
|
||||
## Step 4: Have fun with Teleport!
|
||||
|
||||
Congrats! You've completed setting up Teleport! Now, feel free to have fun and explore the many features Teleport has to offer.
|
||||
|
||||
Here are several common commands and operations you'll likely find useful:
|
||||
|
||||
### View Status
|
||||
|
||||
|
|
@ -223,7 +230,7 @@ tsh ls
|
|||
tsh ssh root@node-name
|
||||
```
|
||||
|
||||
### Add a Node to the Cluster
|
||||
### Add a node to the cluster
|
||||
|
||||
Generate a short-lived dynamic join token using `tctl`:
|
||||
|
||||
|
|
@ -282,7 +289,7 @@ Bootstrap a new node:
|
|||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Add an Application to your Teleport cluster
|
||||
### Add an application to your Teleport cluster
|
||||
|
||||
Generate a short-lived dynamic token to join apps:
|
||||
|
||||
|
|
@ -295,7 +302,7 @@ Add a new application:
|
|||
<Tabs>
|
||||
<TabItem label="teleport start">
|
||||
Install Teleport on the target node, then start it using a command as shown below.
|
||||
Review and update `auth-server`, `token`, `app-name` and `app-uri` before running this command.
|
||||
Review and update `auth-server`, `token`, `app-name`, and `app-uri` before running this command.
|
||||
|
||||
```bash
|
||||
sudo teleport start \
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ h1: Introduction
|
|||
Teleport is a Certificate Authority and an Access Plane for your infrastructure.
|
||||
With Teleport you can:
|
||||
|
||||
- Set up single sign-on and have one place to access your SSH servers, Kubernetes, Databases and Web Apps.
|
||||
- Set up single sign-on and have one place to access your SSH servers, Kubernetes, Databases, and Web Apps.
|
||||
- Use your favorite programming language to define access policies to your infrastructure.
|
||||
- Share and record interactive sessions across all environments.
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ With Teleport you can:
|
|||
|
||||
Here are some of the most popular use-cases for Teleport:
|
||||
|
||||
- Use short lived certificates instead of static keys for SSH, Kubernetes, Databases and Web Apps.
|
||||
- Use short lived certificates instead of static keys for SSH, Kubernetes, Databases, and Web Apps.
|
||||
- Gather structured events and session recording/replay for `ssh` and `kubectl`.
|
||||
- Centralized SSH and Kubernetes Certificate Authority.
|
||||
- Enforce 2nd factor auth with U2F or TOTP.
|
||||
|
|
@ -72,18 +72,18 @@ or a commercial edition ("Teleport Enterprise Edition").
|
|||
|
||||
Teleport is officially supported on the platforms listed below. It is worth noting
|
||||
that the open source community has been successful in building and running Teleport on
|
||||
UNIX variants other than Linux \[2].
|
||||
UNIX variants other than Linux \[1].
|
||||
|
||||
| Operating System | Teleport Client | Teleport Server |
|
||||
| - | - | - |
|
||||
| Linux v2.6+ | yes | yes |
|
||||
| MacOS v10.12+ | yes | yes |
|
||||
| Windows \[1] | yes \[1] | no |
|
||||
| Windows \[2] | yes \[2] | no |
|
||||
|
||||
\[1] *Teleport server does not run on Windows yet, but `tsh` (the Teleport client)
|
||||
\[1] *Teleport is written in Go and it's possible to build it on
|
||||
any OS supported by the [Golang toolchain](https://github.com/golang/go/wiki/MinimumRequirements)*.
|
||||
|
||||
\[2] *Teleport server does not run on Windows yet, but `tsh` (the Teleport client)
|
||||
can be used on Windows to execute `tsh login` to retrieve a user's SSH
|
||||
certificate and use it with `ssh`, the OpenSSH client, running on a Windows
|
||||
client machine.*
|
||||
|
||||
\[2] *Teleport is written in Go and it is theoretically possible to build it on
|
||||
any OS supported by the [Golang toolchain](https://github.com/golang/go/wiki/MinimumRequirements)*.
|
||||
client machine.*
|
||||
|
|
@ -4,7 +4,7 @@ description: The guide for installing Teleport on servers and into Kubernetes cl
|
|||
h1: Installation
|
||||
---
|
||||
|
||||
Teleport core service [`teleport`](cli-docs.mdx#teleport) and admin tool [`tctl`](cli-docs.mdx#tctl) have been designed to run on **Linux** and **Mac** operating systems. The Teleport user client [`tsh`](cli-docs.mdx#tsh) and UI are available for **Linux, Mac** and **Windows** operating systems.
|
||||
Teleport core service [`teleport`](cli-docs.mdx#teleport) and admin tool [`tctl`](cli-docs.mdx#tctl) have been designed to run on **Linux** and **Mac** operating systems. The Teleport user client [`tsh`](cli-docs.mdx#tsh) and UI are available for **Linux, Mac**, and **Windows** operating systems.
|
||||
|
||||
## Linux
|
||||
|
||||
|
|
|
|||
|
|
@ -216,10 +216,10 @@ hijack the IP address of the auth server.
|
|||
|
||||
To prevent this from happening, you need to supply every new node with an
|
||||
additional bit of information about the auth server. This technique is called
|
||||
"CA pinning". It works by asking the auth server to produce a "CA pin", which
|
||||
*CA pinning*. It works by asking the auth server to produce a *CA pin*, which
|
||||
is a hashed value of its private key, i.e. it cannot be forged by an attacker.
|
||||
|
||||
To get the current CA pin run this on the auth server:
|
||||
To get the current CA pin run the following code on the auth server:
|
||||
|
||||
```bash
|
||||
$ tctl status
|
||||
|
|
@ -271,10 +271,10 @@ teleport:
|
|||
### Secure Data Storage
|
||||
|
||||
By default the `teleport` daemon uses the local directory `/var/lib/teleport` to
|
||||
store its data. This applies to any role or service including Auth, Node, or Proxy.
|
||||
While an Auth node hosts the most sensitive data you will want to prevent
|
||||
store its data. This applies to any role or service including `auth`, `node`, or `proxy`.
|
||||
While an `auth` node hosts the most sensitive data you will want to prevent
|
||||
unauthorized access to this directory. Make sure that regular/non-admin users
|
||||
do not have access to this folder, particularly on the Auth server. Change
|
||||
do not have access to this folder, particularly on the `auth` server. Change
|
||||
the ownership of the directory with [`chown`](https://linuxize.com/post/linux-chown-command/)
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -97,8 +97,8 @@ $ tsh login --proxy=work.example.com:2002
|
|||
|
||||
| Port | Description |
|
||||
| - | - |
|
||||
| https_proxy_port | the HTTPS port the proxy host is listening to (defaults to 3080). |
|
||||
| ssh_proxy_port | the SSH port the proxy is listening to (defaults to 3023). |
|
||||
| https_proxy_port | the HTTPS port the proxy host is listening to (defaults to `3080`). |
|
||||
| ssh_proxy_port | the SSH port the proxy is listening to (defaults to `3023`). |
|
||||
|
||||
The login command retrieves a user's certificate and stores it in `~/.tsh`
|
||||
directory as well as in the [ssh
|
||||
|
|
@ -120,7 +120,7 @@ with a TTL (time to live) of 12 hours.
|
|||
</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
|
||||
example, a cluster may have a local user called `admin` while regular users
|
||||
should [authenticate via Github](admin-guide.mdx#github-oauth-20). In this case,
|
||||
you have to pass `--auth` flag to `tsh login` to specify which identity storage
|
||||
to use:
|
||||
|
|
@ -198,7 +198,7 @@ $ tsh ssh --proxy=proxy.example.com -i joe joe@db
|
|||
|
||||
By default, `--out` flag will create an identity file suitable for `tsh -i` but
|
||||
if compatibility with OpenSSH is needed, `--format=openssh` must be specified.
|
||||
In this case the identity will be saved into two files: `joe` and
|
||||
In this case, the identity will be saved into two files: `joe` and
|
||||
`joe-cert.pub`:
|
||||
|
||||
```bash
|
||||
|
|
@ -223,7 +223,7 @@ For such automation, it is recommended to create a separate Teleport user for
|
|||
bots and request a certificate for them with a long time to live (TTL).
|
||||
|
||||
In this example we're creating a certificate with a TTL of 10 years for the
|
||||
jenkins user and storing it in jenkins.pem file, which can be later used with
|
||||
jenkins user and storing it in a `jenkins.pem` file, which can be later used with
|
||||
`-i` (identity) flag for `tsh`.
|
||||
|
||||
```bash
|
||||
|
|
@ -278,7 +278,7 @@ To launch an interactive shell on a remote node or to execute a command, use
|
|||
|
||||
`tsh` tries to mimic the `ssh` experience as much as possible, so it supports
|
||||
the most popular `ssh` flags like `-p`, `-l` or `-L`. For example, if you have
|
||||
the following alias defined in your ~/.bashrc: `alias ssh="tsh ssh"` then you
|
||||
the following alias defined in your `~/.bashrc`: `alias ssh="tsh ssh"` then you
|
||||
can continue using familiar SSH syntax:
|
||||
|
||||
```bash
|
||||
|
|
@ -343,9 +343,9 @@ $ tsh ssh -L 5000:google.com:80 --local node curl http://localhost:5000
|
|||
This command:
|
||||
|
||||
1. Connects to `node`
|
||||
2. Binds the local port 5000 to port 80 on google.com
|
||||
2. Binds the local port `5000` to port `80` on `google.com`
|
||||
3. Executes `curl` command locally, which results in `curl` hitting
|
||||
google.com:80 via `node`
|
||||
`google.com:80` via `node`
|
||||
|
||||
### SSH Jumphost
|
||||
|
||||
|
|
@ -355,7 +355,7 @@ While implementing ProxyJump for Teleport, we have extended the feature to `tsh`
|
|||
$ tsh ssh -J proxy.example.com telenode
|
||||
```
|
||||
|
||||
Known limits:
|
||||
Known limitations:
|
||||
|
||||
- Only one jump host is supported (`-J` supports chaining that Teleport does not utilise) and `tsh` will return with error in the case of two jumphosts, i.e. `-J proxy-1.example.com,proxy-2.example.com` will not work.
|
||||
- When `tsh ssh -J user@proxy` is used, it overrides the SSH proxy defined in the tsh profile and port forwarding is used instead of the existing Teleport proxy subsystem.
|
||||
|
|
@ -364,10 +364,10 @@ Known limits:
|
|||
|
||||
`tsh` supports multiple methods to resolve remote node names.
|
||||
|
||||
1. Traditional: by IP address or via DNS.
|
||||
2. Nodename setting: teleport daemon supports `nodename` flag, which allows
|
||||
1. **Traditional**: by IP address or via DNS.
|
||||
2. **Nodename setting**: teleport daemon supports `nodename` flag, which allows
|
||||
Teleport administrators to assign alternative node names.
|
||||
3. Labels: you can address a node by `name=value` pair.
|
||||
3. **Labels**: you can address a node by `name=value` pair.
|
||||
|
||||
If we have two nodes, one with `os:linux` label and one node with `os:osx`, we
|
||||
can log into the OSX node with:
|
||||
|
|
@ -425,7 +425,7 @@ it makes sense to ask another team member for help. Traditionally, this could be
|
|||
done by letting them know which node you're on, having them SSH in, start a
|
||||
terminal multiplexer like `screen` and join a session there.
|
||||
|
||||
Teleport makes this more convenient. Let's log into a server named "luna"
|
||||
Teleport makes this more convenient. Let's log into a server named `luna`
|
||||
and ask Teleport for our current session status:
|
||||
|
||||
```bash
|
||||
|
|
@ -437,7 +437,7 @@ Session ID : 7645d523-60cb-436d-b732-99c5df14b7c4
|
|||
Session URL: https://work:3080/web/sessions/7645d523-60cb-436d-b732-99c5df14b7c4
|
||||
```
|
||||
|
||||
Now you can invite another user account to the "work" cluster. You can share the
|
||||
Now you can invite another user account to the `work` cluster. You can share the
|
||||
URL for access through a web browser, or you can share the session ID and she
|
||||
can join you through her terminal by typing:
|
||||
|
||||
|
|
@ -455,10 +455,10 @@ Teleport supports creating clusters of servers located behind firewalls
|
|||
**without any open listening TCP ports**. This works by creating reverse SSH
|
||||
tunnels from behind-firewall environments into a Teleport proxy you have access to.
|
||||
|
||||
This feature is called ["Trusted Clusters"](https://gravitational.com/teleport/docs/trustedclusters/). Refer to
|
||||
These features are called [*Trusted Clusters*](https://gravitational.com/teleport/docs/trustedclusters/). Refer to
|
||||
[the admin manual](admin-guide.mdx#trusted-clusters) to learn how a trusted cluster can be configured.
|
||||
|
||||
Assuming the "work" Teleport proxy server is configured with a few trusted
|
||||
Assuming the `work` Teleport proxy server is configured with a few trusted
|
||||
clusters, a user may use the `tsh clusters` command to see a list of all clusters on the server:
|
||||
|
||||
```bash
|
||||
|
|
@ -472,7 +472,7 @@ production offline
|
|||
|
||||
[CLI Docs - tsh clusters](cli-docs.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 do:
|
||||
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 do:
|
||||
|
||||
```bash
|
||||
$ tsh --proxy=work ls --cluster=production
|
||||
|
|
@ -489,8 +489,8 @@ $ tsh --proxy=work 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 "work" proxy, and this tunnel is used
|
||||
firewall without open ports. This works because the `production` cluster
|
||||
establishes a reverse SSH tunnel back into `work` proxy, and this tunnel is used
|
||||
to establish inbound SSH connections.
|
||||
|
||||
## Web UI
|
||||
|
|
@ -575,8 +575,8 @@ Host teleport.proxy
|
|||
|
||||
If a user does not want to use an SSH agent or if the agent is not available,
|
||||
the certificate must be passed to `ssh` via `IdentityFile` option (see `man
|
||||
ssh_config`). Consider this example: the Teleport user "joe" wants to login into
|
||||
the proxy named "lab.example.com".
|
||||
ssh_config`). Consider this example: the Teleport user `joe` wants to login into
|
||||
the proxy named `lab.example.com`.
|
||||
|
||||
He executes the [`tsh login`](cli-docs.mdx#tsh-login) command:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue