Fix SELinux Enforced Mode Preventing SSH Connection on Rocky Linux 8.10

SSH connections failing on Rocky Linux 8.10 due to SELinux enforced mode typically occur because the security context for SSH ports or directories is misconfigured, causing the system to block access despite correct network settings. This guide resolves the issue by verifying and correcting file contexts using standard diagnostic commands and applying persistent fixes without disabling security protections.

Diagnosing the SELinux Block

When SELinux operates in Enforcing mode, it strictly controls process access to files and network ports based on defined policies. If an SSH connection fails immediately after authentication or hangs during the handshake, SELinux is likely intervening. The first step is to confirm that SELinux is indeed the culprit rather than a firewall rule or network configuration error. You can check the current status of SELinux by running the sestatus command. Look for the line labeled "SELinux status" which should read "enabled" and "Current mode" which should display "enforcing". If the mode is set to "permissive", SELinux logs violations but does not block them, so this specific fix would not apply. To see if recent denials have occurred, inspect the audit log using ausearch -m avc -ts recent. If you see entries related to sshd or port 22, SELinux is actively blocking traffic. It is crucial to distinguish between a network block and a policy block. A firewall block usually results in a timeout, whereas a SELinux block often manifests as an immediate disconnect or an authentication failure even with valid credentials. Checking the system journal with journalctl -xe | grep sshd can reveal AVC (Access Vector Cache) denial messages that confirm the source of the problem.

Verifying Port Contexts

One common cause for SSH failures is an incorrect security context assigned to the port definition. By default, SSH should listen on port 22 with the context ssh_port_t. If this context has been altered, either manually or by another service, SELinux will reject the connection. You can verify the current port context by running semanage port -l | grep ssh. The output should list ssh_port_t associated with tcp port 22. If this entry is missing or points to a different port, the SSH daemon cannot bind correctly under SELinux policies. In such cases, you must restore the correct context using the semanage port -a -t ssh_port_t -p tcp 22 command. Note that if the port is already defined with a wrong type, you may need to remove it first with semanage port -d before adding it back correctly. This step ensures that the network layer respects the SELinux policy for the SSH service. Without the correct port context, the sshd process is treated as untrusted when attempting to accept incoming connections on the specified port.

Checking File and Directory Contexts

Beyond ports, SELinux enforces strict rules on where SSH keys and configuration files reside. If you have moved the /etc/ssh directory or changed home directory structures, the file contexts may no longer match the expected labels. Use the ls -Z /etc/ssh command to view the current security contexts of SSH configuration files. They should generally carry the etc_t or specific SSH-related types depending on the file. Home directories containing authorized keys must also have the correct context, typically user_home_dir_t for the directory and ssh_home_t for the key files. If these labels are incorrect, sshd will refuse to read the keys, leading to authentication failures. You can reset the contexts for the SSH configuration directory by running restorecon -Rv /etc/ssh. This command recursively restores the default SELinux contexts based on the policy database. For user-specific issues, ensure that the .ssh directory and its contents have the proper permissions and contexts. Running restorecon -Rv ~/.ssh can fix context mismatches for individual users. It is important to note that changing file contexts does not alter traditional Unix permissions, so ensure that ownership and read/write bits are still correctly configured alongside SELinux labels.

Applying Persistent Fixes

Temporary changes made via command line might be overwritten by future package updates or system reboots if not handled correctly. To make your SELinux adjustments permanent, rely on the management tools that interact directly with the policy store. Commands like semanage modify the policy database, ensuring that port definitions persist across reboots. If you have made custom changes to file contexts, consider creating a custom module if the standard restorecon does not suffice. However, in most cases, resetting contexts to their defaults resolves the majority of SSH connectivity issues. Always restart the SSH service after making changes to ensure the daemon picks up the new security contexts. Use systemctl restart sshd to apply the changes immediately. Testing the connection again after these steps should yield successful authentication. If problems persist, review the audit logs once more to identify any remaining denials. Remember that disabling SELinux is not a recommended long-term solution, as it removes critical security protections for your Rocky Linux 8.10 server.

Frequently Asked Questions

Can I disable SELinux to fix the SSH issue?

Disabling SELinux is possible by setting the mode to permissive in /etc/selinux/config, but it is strongly discouraged for production servers. Doing so exposes your system to potential security vulnerabilities and violates best practices for enterprise Linux distributions like Rocky Linux.

What if semanage commands fail with permission denied?

These commands require root privileges, so ensure you are executing them with sudo or as the root user. Additionally, verify that the policycoreutils-python-utils package is installed, as it provides the necessary tools for managing SELinux policies.

How do I know if my SSH keys have the right context?

Use ls -Z ~/.ssh/authorized_keys to check the label. It should typically be ssh_home_t. If it shows default_t or another generic type, run restorecon -v ~/.ssh/authorized_keys to correct it.

Does fixing SELinux affect other services?

Correcting contexts for SSH specifically targets the SSH daemon and its related files. It does not impact unrelated services unless they share the same misconfigured directories or ports, which is rare in standard configurations.

Why does SSH work locally but not remotely?

Local console access bypasses network-based SELinux checks on port bindings. Remote connections trigger the full SELinux policy evaluation for network ports and file access, revealing context errors that local testing might miss.