Restricting SSH access for the wheel group in Red Hat 9 requires configuring pam_access.so correctly within the PAM stack. The common failure occurs when rules are misplaced or syntax is incorrect, leading to unintended access denial or allowance. This guide details the precise configuration steps to ensure only authorized users can connect via SSH.
Understanding PAM and SSH Authentication
Pluggable Authentication Modules (PAM) provide a flexible way to manage authentication on Linux systems. In Red Hat Enterprise Linux 9, the default SSH server configuration relies heavily on PAM to handle user credentials and access control. When you attempt to restrict access based on group membership, such as thewheel group, you must interact with the PAM stack rather than modifying sshd_config directly.
The module responsible for host-based and user-based access control is pam_access.so. It reads its rules from /etc/security/access.conf. If this module is not included in the authentication chain for SSH, or if the rules are malformed, the restriction will fail silently or behave unpredictably. It is crucial to understand that PAM processes modules sequentially, and the order of inclusion matters significantly for security policies.
Configuring /etc/security/access.conf
The core logic for restricting access resides in/etc/security/access.conf. This file uses a simple syntax: :user-list:addr-list. To deny SSH access to all members of the wheel group, you need to add a specific rule. However, the order of rules is critical because PAM evaluates them top-down until it finds a match.
Add the following line to /etc/security/access.conf:
- : wheel : ALL-) access for any user (: implies all users unless specified otherwise, but here we target the group wheel) from any address (ALL). Note that the colon-separated fields define the user list, the command list (often omitted for general access), and the host list.
If you want to allow other users while denying only the wheel group, you might also need an explicit allow rule for others, depending on your overall security posture. Typically, a + : ALL : ALL rule at the end ensures everyone else is permitted. Without this catch-all, subsequent connections might be denied by default if no matching rule is found.
Integrating pam_access.so into SSH PAM Stack
Defining the rule inaccess.conf is insufficient if the PAM module is not invoked during the SSH session. You must edit the PAM configuration file for the SSH service, located at /etc/pam.d/sshd. Open this file with a text editor and look for existing pam_access entries.
If pam_access.so is already present, ensure it is positioned correctly. It should typically be placed in the account section, as access control is an account-level decision rather than an authentication one. A correct entry looks like this:
account required pam_access.soaccount stack ensures that access restrictions are evaluated before other account-related checks proceed. For Red Hat 9, the default configuration often includes this module, but it may be commented out or configured permissively. Uncommenting or adding it explicitly enforces the rules defined in access.conf.
Verifying SELinux and Systemd Contexts
In modern Red Hat systems, SELinux plays a role in enforcing security policies. Whilepam_access.so operates primarily through standard file permissions and kernel calls, ensuring that the PAM configuration files have the correct contexts prevents unexpected denials. Use restorecon -v /etc/pam.d/sshd and restorecon -v /etc/security/access.conf to reset contexts if they have been altered manually.
Additionally, verify that the SSH daemon is using the updated PAM configuration. Restarting the SSH service applies the changes:
sudo systemctl restart sshdwheel group. You should receive an "Access denied" message. Conversely, a user outside the group should connect successfully. Check /var/log/secure for detailed logs if the behavior is not as expected. Look for entries related to pam_access to see which rule matched.
For more insights on managing SSH configurations, consider reading about Understanding KEX Algorithms in sshd_config to ensure your cryptographic settings do not interfere with authentication flows. Also, exploring Configuring a Groupable SSH Server might provide broader context on group-based access management across different distributions, even though the specific PAM implementation differs.
Troubleshooting Common Issues
A frequent mistake is placing the deny rule after an allow rule. Since PAM stops at the first match, an earlier+ : ALL : ALL rule would grant access to the wheel group before the deny rule is ever evaluated. Always place restrictive rules before permissive ones.
Another issue arises from misinterpreting the user list field. In access.conf, specifying wheel targets the group. If you specify a username, it targets that individual. Ensure you are targeting the group name exactly as it appears in /etc/group.
Finally, remember that PAM changes require a new login session to take effect. Existing SSH sessions will continue to operate under the old rules until disconnected. Always test with a new terminal window to confirm the restrictions are active.
Frequently Asked Questions
Does pam_access.so affect SFTP sessions?
Yes, because SFTP runs over the SSH protocol, it inherits the same PAM authentication and account checks. If a user is denied SSH access via pam_access.so, they will also be unable to establish an SFTP connection. This applies to both interactive shells and subsystem requests like SFTP.
What happens if I comment out pam_access.so in sshd?
Commenting out the module disables the access control checks entirely. All users who pass the authentication stage (username/password or key) will be granted access, regardless of the rules in access.conf. This effectively removes the group restriction you intended to implement.
Can I use pam_access.so to restrict by IP address?
Absolutely. The third field in the access.conf rule allows you to specify host addresses or networks. For example, - : wheel : 192.168.1.0/24 would deny the wheel group only if they connect from that specific subnet. This provides granular control over where these users can log in from.
Is there a performance impact of using pam_access.so?
The performance impact is negligible for most environments. The module performs a simple string matching operation against the configuration file. Unless you have thousands of complex rules or extremely high-frequency login attempts, the latency added is imperceptible to the user.
How do I temporarily bypass the restriction for testing?
You can comment out the account required pam_access.so line in /etc/pam.d/sshd and restart the SSH service. Alternatively, you can modify access.conf to remove or comment out the specific deny rule for the wheel group. Remember to revert these changes after testing to maintain security.