final edits from ann ming

Author: deadlypants1973

src/content/docs/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access.mdx

@@ -193,34 +193,34 @@ SSH sessions have a maximum expected duration of 10 hours. For more information,
 
 Failure to connect to your SSH endpoint could be the result of multiple variables. Use the following steps to investigate and resolve the source of your connection failure.
 
-1. [Verify that your Access policies](#1-review-access-policies) allow the user to access the target machine.
+1. [Verify that your Access policies](#1-review-access-policies) allow the user to access the target.
 2. [Check Cloudflare Tunnel](#2-check-target-machine-connection) health.
-3. [Confirm user existence](#3-confirm-user-existence-on-the-target-server) on the target server.
+3. [Confirm user existence](#3-confirm-user-existence-on-the-target-server) on the server.
 4. [Check your `sshd_config` file](#4-debug-sshd_config-file-misconfiguration) for misconfiguration.
 
 ### 1. Review Access policies
 
-A user may be blocked by an Access policy from reaching an SSH target because no explicit allow Access policy exists and Access is set to deny the user by default.
+A user may be blocked by an Access policy from reaching your server because no explicit allow Access policy exists and Access is set to deny the user by default.
 
 :::note[Access policies and infrastructure applications]
 
-The Access infrastructure application (created in [step 5](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#5-add-an-infrastructure-application)) is the policy container for your SSH server. Cloudflare refers to your SSH server as a [target](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#4-add-a-target).
+The Access infrastructure application (created in [step 5](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#5-add-an-infrastructure-application)) is the policy container for your SSH server. Cloudflare refers to your server that you connect to with SSH as a [target](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#4-add-a-target).
 
 [Access policies](/cloudflare-one/policies/access/policy-management/) are the rules attached to this Access infrastructure application, determining who can connect and what UNIX usernames they can log in as on the server. Cloudflare will not create new users on the target. UNIX users must already be present on the server.
 
-You were guided to create an Access policy for your SSH target in [substep 9 of step 5: Add an infrastructure application](#5-add-an-infrastructure-application).
+You were guided to create an Access policy for your target in [substep 9 of step 5: Add an infrastructure application](#5-add-an-infrastructure-application).
 
 :::
 
 #### End users
 
-As an end user, run [`warp-cli target list`](/cloudflare-one/applications/non-http/infrastructure-apps/#display-available-targets) to verify that you have access to the target machine.
+As an end user, run [`warp-cli target list`](/cloudflare-one/applications/non-http/infrastructure-apps/#display-available-targets) to verify that you have access to the target.
 
 <Render file="tunnel/warp-cli-target-list" product="cloudflare-one" />
 
-- If the target appears in the list, confirm that the username you are attempting to connect with is shown in the output. If the username is not shown, an administrator must find the Access policy associated with the target machine and add that username to the Access policy. An administrator should have created an Access policy in [substep 9 of step 5: Add an infrastructure application](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#5-add-an-infrastructure-application). If the username is shown, that means the Access policy should be granting access and you should ensure that the tunnel is healthy in [step 2](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#2-check-target-machine-connection).
+- If the target appears in the list, confirm that the username you are attempting to connect with is shown in the output. If the username is not shown, an administrator must find the Access policy associated with the target and add that username to the Access policy. An administrator should have created an Access policy in [substep 9 of step 5: Add an infrastructure application](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#5-add-an-infrastructure-application). If the username is shown, that means the Access policy should be granting access and you should ensure that the tunnel is healthy in [step 2](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#2-check-target-machine-connection).
 
-- If the target does not appear in the list, an administrator must audit the Access policies for the target machine in the Zero Trust dashboard for potential misconfiguration that may be blocking connection.
+- If the target does not appear in the list, an administrator must audit the Access policies for the target in the Zero Trust dashboard for potential misconfiguration that may be blocking connection.
 
 #### Administrators
 
@@ -238,7 +238,7 @@ You will need Cloudflare dashboard access and log view [permissions](/cloudflare
 
 3. Review the **Decision**. If the **Decision** is `Access denied`, select the application and copy the name under App.
 
-	If the decision is `Access granted`, Access policies are not interfering with your connection attempts and your connection issue is due to the Cloudflare Tunnel, the target SSH machine, or the `sshd_config` file.
+	If the decision is `Access granted`, Access policies are not interfering with your connection attempts and your connection issue is due to the Cloudflare Tunnel ([step 2](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#2-check-target-machine-connection)), the SSH server ([step 3](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#3-confirm-user-existence-on-the-target-server)), or the `sshd_config` file ([step 4](/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/#4-debug-sshd_config-file-misconfiguration)).
 
 4. Go to **Access** > **Applications**.
 
@@ -248,13 +248,13 @@ You will need Cloudflare dashboard access and log view [permissions](/cloudflare
 
 7. Go to [**Policies**](/cloudflare-one/policies/access/policy-management/#test-your-policies) to review what criteria may be blocking the user.
 
-By adding an Access [policy](/cloudflare-one/policies/access/) to allow the user, the connection issue should be resolved. After saving your policy changes, attempt to connect to the target machine as the end user.
+By adding an Access [policy](/cloudflare-one/policies/access/) to allow the user, the connection issue should be resolved. After saving your policy changes, attempt to connect to the server.
 
 If you are still having connection issues after auditing your Access policies, review tunnel health in the following step.
 
-### 2. Check target machine connection
+### 2. Check target connection
 
-If the end user cannot connect to the target SSH machine, the tunnel you set up in [step 1: Connect the server to Cloudflare](#1-connect-the-server-to-cloudflare) may be down or inactive.
+If the end user cannot connect to the target, the tunnel you set up in [step 1: Connect the server to Cloudflare](#1-connect-the-server-to-cloudflare) may be down or inactive.
 
 To check the status of your tunnel:
 
@@ -276,13 +276,13 @@ To check the status of your tunnel:
 
 For detailed steps on troubleshooting, refer to the [Troubleshooting Tunnel documentation](/cloudflare-one/connections/connect-networks/troubleshoot-tunnels/). Review the [Tunnel with Firewall documentation](/cloudflare-one/connections/connect-networks/configure-tunnels/tunnel-with-firewall/#test-connectivity) to ensure your network is correctly configured to allow `cloudflared` connections.
 
-After you have verified that there are no issues with your tunnel's health, confirm the user's existence on the target SSH server in the following step.
+After you have verified that there are no issues with your tunnel's health, confirm the user's existence on the server in the following step.
 
-### 3. Confirm user existence on the target server
+### 3. Confirm user existence on the server
 
-To verify the existence of the end user on the target SSH server, run the `id <USERNAME>` command on the target SSH server to verify that the end user's username exists. If the username does not exist, you must add the user to the server.
+To verify the existence of the end user on the server, run the `id <USERNAME>` command on the server to verify that the end user's username exists. If the username does not exist, you must add the user to the server.
 
-If the user exists on the target machine, debug your `sshd_config` file in the following step.
+If the user exists on the server, debug your `sshd_config` file in the following step.
 
 ### 4. Debug `sshd_config` file misconfiguration
 
@@ -292,7 +292,7 @@ One reason a user is failing to connect to your SSH endpoint might be the result
 
 `sshd` logs can confirm whether or not the user is making it to the server. The location of your `sshd` logs is defined in your `sshd_config`. The logs location is likely at `journalctl -u ssh` on Ubuntu and `tail /var/log/auth.log` for Red Hat.
 
-Using your `sshd` logs, validate that SSH connection attempts are arriving to the SSH target machine.
+Using your `sshd` logs, validate that SSH connection attempts are arriving to the server.
 
 #### Review your `sshd_config` file for misconfigurations
 
@@ -441,7 +441,7 @@ Subsystem    sftp    /usr/lib/openssh/sftp-server
 
 The next steps will walk you through a troubleshooting regimen. You will temporarily replace your existing `sshd_config` file with the provided example to rule out configuration issues. Before proceeding, carefully [review and compare both files](#review-your-sshd_config-file-for-misconfigurations) to identify any conflicting directives.
 
-:::caution[You may lose access to your SSH server]
+:::caution[You may lose access to your server]
 
 These troubleshooting steps could result in you being locked out of your SSH server because your current SSH session may rely on existing configuration that is not in the [example file](#review-your-sshd_config-file-for-misconfigurations). Proceed with utmost caution.