[enterprise-4.19] OCPBUGS-85278: Updated the security-command-line-host-access.adoc fil…

modules/security-command-line-host-access.adoc

@@ -6,16 +6,19 @@
 [id="security-command-line-host-access_{context}"]
 = Command-line host access
 
-Direct access to a host must be restricted to avoid modifying the host or accessing pods that should not be accessed. For users who need direct access to a host, it is recommended to use an external authenticator, like SSSD with LDAP, to manage access. This helps maintain consistency across the cluster through the Machine Config Operator.
+[role="_abstract"]
+Configure an external authenticator to restrict direct access and prevent unauthorized modifications. The Machine Config Operator (MCO) manages these logins and maintains consistency across your cluster.
+
+Examples of external authenticators include lightweight directory access protocol (LDAP) and System Security Services Daemon (SSSD). If a node reboot leads to timeout issues, create a node disruption policy. With this policy, you can configure an external authenticator on a host without requiring a node reboot. For more information, see "Using node disruption policies to minimize disruption from machine config changes" in the _Additional resources_ section.
 
 [IMPORTANT]
 ====
 Do not configure direct access to the root ID on any {product-title} cluster server.
 ====
 
-You can connect to a node in the cluster using the following methods:
+You can connect to a node in the cluster by using the following methods:
 
-Using debug pod:: This is the recommended method to access a node. To debug or connect to a node, run the following command:
+Using debug pod:: Red{nbsp}Hat recommends this method to access a node. To debug or connect to a node, run the following command:
 +
 [source,terminal]
 ----
@@ -31,7 +34,7 @@ After connecting to the node, run the following command to get access to the roo
 +
 This gives you root access within a debug pod on the node. For more information, see "Starting debug pods with root access".
 
-Direct SSH:: Avoid using the root user. Instead, use the core user ID (or your own ID). To connect to the node using SSH, run the following command:
+Direct SSH:: Avoid using the root user. Instead, use the core user ID (or your own ID). To connect to the node by using SSH, run the following command:
 +
 [source,terminal]
 ----
@@ -43,7 +46,7 @@ $ ssh core@<worker_node_name>
 The core user ID is initially given `sudo` privileges within the cluster.
 ====
 +
-If you cannot connect to a node using SSH, see link:https://access.redhat.com/solutions/4073041[How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod] to add your SSH key to the core user.
+If you cannot connect to a node by using SSH, add your SSH key to the core user. For more information, see "How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod" in the _Additional resources_ section.
 +
 After connecting to the node using SSH, run the following command to get access to the root shell:
 +

post_installation_configuration/day_2_core_cnf_clusters/security/security-host-sec.adoc

@@ -22,6 +22,10 @@ include::modules/security-command-line-host-access.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
+* xref:../../../machine_configuration/machine-config-node-disruption.adoc#machine-configs-configure_machine-config-node-disruption[Using node disruption policies to minimize disruption from machine config changes]
+
 * xref:../../../support/troubleshooting/investigating-pod-issues.adoc#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access]
 
+* link:https://access.redhat.com/solutions/4073041[How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod]
+
 include::modules/security-linux-capabilities-overview.adoc[leveloffset=+1]