[v16] docs: use code styling instead of bash (#47749)

* docs: use code styling instead of bash

* docs: revert host user creation

* docs: add prompt for tctl

docs/pages/admin-guides/access-controls/access-monitoring.mdx

@@ -143,7 +143,7 @@ Below, you can find the IAM permissions that allow the Auth Service to execute A
 You can use our [Terraform Example](https://github.com/gravitational/teleport/tree/v(=teleport.version=)/examples/athena)
 to set up Athena and Access Monitoring AWS resources and generate Athena Backend and Access Monitoring Teleport configuration:
 
-```bash
+```code
 $ terraform apply
 ...
  access_monitoring:

docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx

@@ -277,7 +277,7 @@ DEBU   Mattermost API health check finished ok mattermost/main.go:19
 
 Run the plugin:
 
-```bash
+```code
 $ docker run -v <path-to-config>:/etc/teleport-mattermost.toml public.ecr.aws/gravitational/teleport-plugin-mattermost:(=teleport.version=) start
 ```
 </TabItem>

docs/pages/admin-guides/access-controls/device-trust/guide.mdx

@@ -173,7 +173,7 @@ The presence of the `teleport-device-*` extensions shows that the device was suc
 
 Now, let's try to access server (`(=clusterDefaults.nodeIP=)`) again:
 
-```bash
+```code
 $ tsh ssh root@(=clusterDefaults.nodeIP=)
 root@(=clusterDefaults.nodeIP=):~#
 ```

docs/pages/admin-guides/access-controls/idps/saml-gcp-workforce-identity-federation.mdx

@@ -248,7 +248,7 @@ spec:
 Replace **pool_name** and **pool_provider_name** values with the workforce pool and pool provider names you used in step 1.
 
 Save the spec as **pool_provider_name.yaml** file. And create the saml service provider resource.
-```bash
+```code
 $ tctl create pool_provider_name.yaml
 ```
 

docs/pages/admin-guides/infrastructure-as-code/terraform-provider/dedicated-server.mdx

@@ -53,7 +53,7 @@ At this point, `tbot` is installed and configured on the machine that will run T
 Use the `tctl bots update` command to add the role to the Bot. Replace `example`
 with the name of the Bot you created in the deployment guide.
 
-```bash
+```code
 $ tctl bots update example --add-roles terraform-provider
 ```
 

docs/pages/admin-guides/management/guides/ec2-tags.mdx

@@ -12,7 +12,7 @@ so newly created or deleted tags will be reflected in the labels.
 
 If the tag `TeleportHostname` (case-sensitive) is present, its value will override the node's hostname.
 
-```bash
+```code
 $ tsh ls
 Node Name            Address        Labels                                                                                                                  
 -------------------- -------------- ----------------------------------------------------------------------------------------------------------------------- 

docs/pages/admin-guides/management/guides/gcp-tags.mdx

@@ -20,7 +20,7 @@ so newly created or deleted tags will be reflected in the labels.
 If the GCP label `TeleportHostname` (case-sensitive) is present, its value will override the node's hostname. This
 does not apply to GCP tags.
 
-```bash
+```code
 $ tsh ls
 Node Name            Address        Labels                                                                                                                  
 -------------------- -------------- -------------------------------------------------------------------------------------------

docs/pages/connect-your-client/gui-clients.mdx

@@ -30,7 +30,7 @@ You won't need to configure any credentials when connecting to this tunnel.
 
 Here is an example on how to start the proxy:
 
-```bash
+```code
 # Start the local proxy.
 $ tsh proxy db --tunnel <database-name>
 Started authenticated tunnel for the <engine> database "<database-name>" in cluster "<cluster-name>" on 127.0.0.1:62652.

docs/pages/connect-your-client/putty-winscp.mdx

@@ -49,16 +49,16 @@ To add saved sessions to PuTTY:
 
 1. Sign into a Teleport cluster using the `tsh login` command:
 
-```bash
-C:\Users\gus>tsh login --proxy=teleport.example.com
+```code
+$ tsh login --proxy=teleport.example.com
 ```
 
 This command retrieves your user certificates and saves them in a local file in the `%USERPROFILE%/.tsh` directory.
 
 2. List SSH nodes that the user can connect to inside the cluster:
 
-```bash
-C:\Users\gus>tsh ls
+```code
+$ tsh ls
 Node Name                           Address        Labels
 ----------------------------------- -------------- ----------------------------
 ip-172-31-30-140                    127.0.0.1:3022 company=acmecorp,env=aws,...
@@ -71,8 +71,8 @@ ip-172-31-8-63                      172.31.8.63:22 type=openssh
 For example, you can add a saved session for the login `ubuntu` on the node `ip-172-31-30-140` to the Windows
 registry by running the following command:
 
-```bash
-C:\Users\gus>tsh puttyconfig ubuntu@ip-172-31-30-140
+```code
+$ tsh puttyconfig ubuntu@ip-172-31-30-140
 Added PuTTY session for ubuntu@ip-172-31-30-140 [proxy:teleport.example.com]
 ```
 
@@ -82,8 +82,8 @@ If you are adding a session for a registered OpenSSH node within your cluster (a
 [`teleport join openssh`](../enroll-resources/server-access/openssh/openssh-agentless.mdx)), you must specify the `sshd` port
 (usually 22) when adding a session with `tsh puttyconfig`:
 
-```bash
-C:\Users\gus>tsh puttyconfig --port 22 ubuntu@ip-172-31-8-63
+```code
+$ tsh puttyconfig --port 22 ubuntu@ip-172-31-8-63
 Added PuTTY session for ubuntu@ip-172-31-8-63 [proxy:teleport.example.com]
 ```
 
@@ -94,16 +94,16 @@ You can also use `tsh puttyconfig user@host:22` if you prefer.
 
 1. Sign into a Teleport cluster using the `tsh login` command:
 
-```bash
-C:\Users\gus>tsh login --proxy=mytenant.teleport.sh
+```code
+$ tsh login --proxy=mytenant.teleport.sh
 ```
 
 This command retrieves your user certificates and saves them in a local file in the `%USERPROFILE%/.tsh` directory.
 
 2. List SSH nodes that the user can connect to inside the cluster:
 
 ```
-C:\Users\gus>tsh ls
+$ tsh ls
 Node Name                           Address        Labels
 ----------------------------------- -------------- ----------------------------
 ip-172-31-30-140                    ⟵ Tunnel      company=acmecorp,env=aws,...
@@ -115,8 +115,8 @@ ip-172-31-34-128.us-east-2.compu... ⟵ Tunnel      access=open,enhanced_reco...
 For example, you can add a saved session for the login `ubuntu` on the node `ip-172-31-30-140` to the Windows
 registry by running the following command:
 
-```bash
-C:\Users\gus>tsh puttyconfig ubuntu@ip-172-31-30-140
+```code
+$ tsh puttyconfig ubuntu@ip-172-31-30-140
 Added PuTTY session for ubuntu@ip-172-31-30-140 [proxy:mytenant.teleport.sh]
 ```
 
@@ -154,8 +154,8 @@ recording of the session after you stop the session and disconnect from the host
 
 To list available leaf clusters, run the following command:
 
-```bash
-C:\Users\gus>tsh clusters
+```code
+$ tsh clusters
 Cluster Name         Status Cluster Type Labels Selected
 -----------------    ------ ------------ ------ --------
 teleport.example.com online root                *
@@ -167,8 +167,8 @@ You can access a leaf cluster in a PuTTY session by adding the `--leaf <leaf clu
 For example, if your leaf cluster is named `example.teleport.sh` and your node is called `ip-172-31-34-128.us-east-2.compute.internal`,
 you can add a PuTTY session for the login `ec2-user` using the following command:
 
-```bash
-C:\Users\gus>tsh puttyconfig --leaf example.teleport.sh [email protected]
+```code
+$ tsh puttyconfig --leaf example.teleport.sh [email protected]
 Added PuTTY session for [email protected] [leaf:example.teleport.sh,proxy:teleport.example.com]
 ```
 

docs/pages/connect-your-client/tsh.mdx

@@ -892,7 +892,7 @@ aliases:
 
 The alias substitution happens before the command line flags are fully parsed. This means that it is not affected by the `--debug` flag. To troubleshoot your aliases, set the `TELEPORT_DEBUG=1` environment variable instead. This will cause the `tsh` logs to be printed to the console:
 
-```bash
+```code
 $ TELEPORT_DEBUG=1 tsh status
 DEBU [TSH]       Self re-exec command: tsh [status --format=json]. tsh/aliases.go:203
 ...
@@ -1065,7 +1065,7 @@ aliases:
 
 To troubleshoot aliases, set the `TELEPORT_DEBUG=1` environment variable. This will cause detailed logs to be printed to standard error:
 
-```bash
+```code
 $ TELEPORT_DEBUG=1 tsh status
 DEBU [TSH]       Self re-exec command: tsh [status --format=json]. tsh/aliases.go:203
 ...
@@ -1137,15 +1137,15 @@ the corresponding cli value will be set.
 If leaf certificates are required to connect to the node, `tsh` automatically
 retrieves leaf certificates from the root cluster:
 
-```bash
+```code
 $ tsh ssh -J {{proxy}} node1.leaf1
 # becomes
 $ tsh ssh -J leaf1.eu.example.com:443 --cluster leaf1 node1
 ```
 
 If there is no template matched, an error is returned.
 
-```bash
+```code
 $ tsh ssh -J {{proxy}} node1.none.example.com
 ERROR: proxy jump contains {{proxy}} variable but did not match any of the templates in tsh config
 ```
@@ -1155,7 +1155,7 @@ attempts to match a template, but won't fail if there isn't a match.
 Additionally, `tsh` won't replace the `proxy` value if it's explicitly set by
 the client:
 
-```bash
+```code
 $ tsh ssh -J leaf2.us.example.com:443 node1.leaf2
 # becomes
 $ tsh ssh -J leaf2.us.example.com:443 --cluster leaf2 node1
@@ -1172,7 +1172,7 @@ Host *.example.com
 
 As a result, you can use `tsh ssh` and `ssh` interchangeably.
 
-```bash
+```code
 $ tsh ssh node1.leaf1
 # is equivalent to
 $ ssh node1.leaf1

docs/pages/enroll-resources/application-access/cloud-apis/aws-console.mdx

@@ -746,7 +746,7 @@ introduced them:
 If you are using `tsh proxy aws` or if your `tsh` version does not contain the
 above fixes, add the following domain to the `NO_PROXY` environment variable
 before running `tsh` commands to ensure the WebSocket connections bypass `tsh`:
-```bash
+```code
 export NO_PROXY=ssmmessages.us-west-1.amazonaws.com
 ```
 

docs/pages/enroll-resources/application-access/okta/scim-only.mdx

@@ -57,7 +57,7 @@ Run the following `tctl` command to install the SCIM integration.
 <Tabs>
 <TabItem label="Without API token">
 
-```bash
+```code
 $ tctl plugins install okta  \
   --org https://trial-12356.okta.com \
   --saml-connector "${SAML_CONNECTOR_NAME}" \
@@ -75,7 +75,7 @@ SCIM Bearer Token: 1234567891234567891234567890
 </TabItem>
 <TabItem label="With API token">
 
-```bash
+```code
 $ tctl plugins install okta  \
   --org https://trial-12356.okta.com \
   --saml-connector "${SAML_CONNECTOR_NAME}" \
@@ -125,7 +125,7 @@ with a subset and/or mapped version of the full User profile.
 You can delete the SCIM integration via the Integrations page in the Teleport UI,
 or with tctl like so:
 
-```bash
+```code
 $ tctl plugins delete okta
 ```
 
@@ -138,7 +138,7 @@ You can semi-manually delete all SCIM-provisioned users using a combination of
 tctl and jq.
 
 For example:
-```bash
+```code
 tctl get users --format=json \
  |  jq '.[] | select(.metadata.labels["teleport.dev/origin"] == "okta") | .metadata.name' -r \
  | xargs -L 1 tctl users rm

docs/pages/enroll-resources/database-access/auto-user-provisioning/mongodb.mdx

@@ -28,7 +28,7 @@ connections.
 
 First create a role on `admin` database with the following privileges:
 
-```bash
+```code
 db.getSiblingDB("admin").runCommand({
     createRole: "teleport-admin-role",
     privileges: [
@@ -49,7 +49,7 @@ To enforce the principle of least privilege, you can limit the `grantRole` to
 only the databases that own the roles to be assigned to the auto-provisioned
 users:
 
-```bash
+```code
 db.getSiblingDB("admin").runCommand({
     createRole: "teleport-admin-role",
     privileges: [
@@ -67,7 +67,7 @@ db.getSiblingDB("admin").runCommand({
 
 Now create the admin user with this role:
 
-```bash
+```code
 db.getSiblingDB("$external").runCommand({
   createUser: "CN=teleport-admin",
   roles: [ { role: 'teleport-admin-role', db: 'admin' } ],

docs/pages/enroll-resources/database-access/enroll-managed-databases/oracle-exadata.mdx

@@ -45,7 +45,7 @@ Adjust the commands to match your configuration.
 
 Connect to the Oracle Exadata VM by logging in as the `opc` user and then switch to the `oracle` user:
 
-```bash
+```code
 $ ssh opc@<Var name="demodb-vm" />
 $ sudo su - oracle
 ```

docs/pages/enroll-resources/database-access/enroll-self-hosted-databases/cockroachdb-self-hosted.mdx

@@ -265,7 +265,7 @@ connecting to your CockroachDB database if your `psql` uses SQL_ASCII encoding.
 
 CockroachDB supports only UTF8 client encoding. To enforce the encoding, set
 the following environment variable in the shell running `tsh db connect`:
-```bash
+```code
 export PGCLIENTENCODING='utf-8'
 ```
 

docs/pages/enroll-resources/database-access/troubleshooting.mdx

@@ -22,7 +22,7 @@ due to expired certificates.
 The command used to generate a new certificate is `tctl auth sign`. For example,
 to create a certificate for PostgreSQL, the command looks like this:
 
-```bash
+```code
 # Export Teleport's certificate authority and a generate certificate/key pair
 # for host db.example.com with a 3-month validity period.
 

docs/pages/enroll-resources/desktop-access/active-directory.mdx

@@ -66,7 +66,7 @@ It may also be easier to comprehend what the script does by following the manual
 
 To use the `tctl` generated configuration script, run the following command:
 
-```bash
+```code
 # Generate the script and save it to a file named configure-ad.ps1.
 tctl desktop bootstrap > configure-ad.ps1
 ```

docs/pages/enroll-resources/kubernetes-access/troubleshooting.mdx

@@ -44,13 +44,13 @@ If the agent is running outside of Kubernetes, the state directory is located
 at `/var/lib/teleport/proc` by default. You can delete the state directory with
 the following command:
 
-```bash
+```code
 sudo rm -rf /var/lib/teleport/proc
 ```
 
 And then restart the agent:
 
-```bash
+```code
 sudo systemctl restart teleport
 ```
 
@@ -60,7 +60,7 @@ Starting in Teleport 11, the `teleport-kube-agent` pod's state is stored in a
 Kubernetes Secret - name:`{pod-name}-state` - existing in the installation namespace.
 To delete the state, follow the steps below:
 
-```bash
+```code
 # Get the secrets for the teleport-kube-agent pods
 $ kubectl get secret -o name -n teleport-agent | grep "state"
 teleport-agent-0-state

docs/pages/enroll-resources/machine-id/access-guides/ansible.mdx

@@ -78,7 +78,7 @@ Now, use `tctl bots update` to add the role to the Bot. Replace `example`
 with the name of the Bot you created in the deployment guide and `example-role`
 with the name of the role you just created:
 
-```bash
+```code
 $ tctl bots update example --add-roles example-role
 ```
 

docs/pages/enroll-resources/machine-id/access-guides/applications.mdx

@@ -52,7 +52,7 @@ Now, use `tctl bots update` to add the role to the Bot. Replace `example`
 with the name of the Bot you created in the deployment guide and `example-role`
 with the name of the role you just created:
 
-```bash
+```code
 $ tctl bots update example --add-roles example-role
 ```
 

docs/pages/enroll-resources/machine-id/access-guides/databases.mdx

@@ -70,7 +70,7 @@ Now, use `tctl bots update` to add the role to the Bot. Replace `example`
 with the name of the Bot you created in the deployment guide and `example-role`
 with the name of the role you just created:
 
-```bash
+```code
 $ tctl bots update example --add-roles example-role
 ```
 

docs/pages/enroll-resources/machine-id/access-guides/kubernetes.mdx

@@ -104,7 +104,7 @@ Now, use `tctl bots update` to add the role to the Bot. Replace `example`
 with the name of the Bot you created in the deployment guide and `example-role`
 with the name of the role you just created:
 
-```bash
+```code
 $ tctl bots update example --add-roles example-role
 ```
 

docs/pages/enroll-resources/machine-id/access-guides/ssh.mdx

@@ -61,7 +61,7 @@ Now, use `tctl bots update` to add the role to the Bot. Replace `example`
 with the name of the Bot you created in the deployment guide and `example-role`
 with the name of the role you just created:
 
-```bash
+```code
 $ tctl bots update example --add-roles example-role
 ```