SSH login hangs on AlmaLinux 9.5 because the session fails to initialize the user environment after authentication succeeds. This usually stems from corrupted shell configuration files, restrictive PAM settings, or SELinux denials that prevent the command prompt from launching.
Understanding the Authentication vs. Session Distinction
When you connect via SSH, two distinct phases occur. First, the server verifies your credentials (authentication). Second, it starts a new shell process for your session (authorization and initialization). In this scenario, the first phase completes successfully, which is why you do not see "Permission denied." However, the second phase fails silently or times out, causing the client to hang until the connection is dropped. This behavior indicates that the issue lies within the user's environment setup rather than network security policies or key management.
Checking Shell Configuration Files
The most common cause is a syntax error in files like
.bash_profile,
.bashrc, or
/etc/profile. If these scripts contain invalid commands or infinite loops, the shell cannot start. To diagnose this, attempt to force a specific shell during connection. Use the following command to bypass standard profile loading:
ssh -t username@server '/bin/bash'
If this works, the problem is isolated to one of the interactive shell startup files. Review these files for typos, missing quotes, or commands that require user interaction (like prompts) which will block non-interactive sessions. For root users, check
/root/.bash_profile specifically, as system-wide profiles might not apply if user-specific overrides exist.
Investigating PAM and Systemd Limits
Pluggable Authentication Modules (PAM) handle session setup. If PAM misconfigures resource limits or fails to allocate a TTY, the session may hang. Check the system logs for PAM-related errors using
journalctl -u sshd. Look for messages indicating failures in
pam_limits.so or
pam_systemd.so.
Additionally, systemd service limits can restrict the number of processes or open files for SSH sessions. If the limit is too low, the shell may fail to spawn necessary background jobs. Verify the current limits by checking
/etc/security/limits.conf and ensuring that
nproc and
nofile are set appropriately for your workload. Restarting the SSH daemon after any changes ensures new limits are applied:
sudo systemctl restart sshd
SELinux and Security Contexts
AlmaLinux enforces strict SELinux policies. If the user's home directory or shell binary has incorrect security contexts, SELinux may block execution without generating a clear error in the SSH log. Check the audit logs for denials:
sudo ausearch -m avc -ts recent
If you find denials related to
shell_exec_t or home directories, restore the default contexts using:
sudo restorecon -Rv /home/username
This command resets the security labels to their expected defaults based on the policy. Incorrect contexts often arise after manual file moves or permission changes that bypass SELinux labeling rules.
Network and DNS Resolution Issues
Sometimes, the hang occurs because the shell attempts to resolve the hostname or perform reverse DNS lookups upon login. If the DNS server is unreachable or slow, the shell may wait indefinitely. Disable reverse DNS lookups in the SSH server configuration by editing
/etc/ssh/sshd_config and setting:
GSSAPIAuthentication no
UseDNS no
Restart the SSH service after making these changes. This forces the server to skip expensive DNS queries during session initialization, often resolving hangs caused by network latency or misconfigured forward/reverse zones.
For more detailed troubleshooting on SSH connectivity issues, refer to our guide on
Troubleshooting kex_exchange_identification Error in Linux SSH Connection and
Fixing Permission Denied with OpenSSH: Manually Adding authorized_keys. These resources cover earlier stages of the connection process that might also contribute to instability.
Testing with Minimal Environment
To isolate whether the issue is user-specific or system-wide, try logging in with a newly created test user. Create a temporary user and attempt an SSH connection:
sudo useradd testuser
sudo passwd testuser
ssh testuser@server
If the test user connects successfully, the problem is confined to the original user's configuration files. If all users hang, the issue is likely systemic, pointing toward PAM, SELinux, or SSH daemon configuration. Always backup configuration files before making changes to avoid locking yourself out of the system.
Frequently Asked Questions
Why does SSH work for some users but not others?
This typically indicates a problem with individual user configuration files like
.bashrc or
.profile. Corrupted scripts or syntax errors in these files prevent the shell from initializing for affected users while leaving others unaffected.
Can I disable SELinux to fix the hang?
Disabling SELinux entirely is not recommended due to security risks. Instead, identify and correct the specific context violations using
restorecon or create custom policy modules if legitimate access is being blocked.
What should I do if journalctl shows no errors?
If logs are silent, the issue may be at the kernel level or related to network timeouts. Try connecting with verbose mode (
-vvv) to see exactly where the client stalls, or check
dmesg for kernel-level alerts related to process creation.
How do I recover if I lock myself out completely?
Access the server via a console interface such as VNC, IPMI, or physical terminal. From there, you can edit configuration files directly or rename problematic shell scripts to allow login, then fix them remotely.
Is GSSAPI authentication required for SSH to work?
No, GSSAPI is optional and used primarily for Kerberos integration. Disabling it (
GSSAPIAuthentication no) can speed up connections and prevent hangs caused by unreachable Kerberos servers.