Intermittent SSH failures with a correct password usually stem from network instability, authentication agent misconfigurations, or server-side resource constraints rather than credential errors. This guide walks you through diagnosing the root cause by examining connection logs, verifying key permissions, and adjusting timeout settings to establish a stable link.
Diagnosing the Connection State
When an SSH connection drops intermittently despite valid credentials, the first step is to determine whether the failure occurs during the handshake, the authentication phase, or after login. Use the verbose mode of the SSH client to gain visibility into exactly where the process halts. Run the command
ssh -vvv user@host and observe the output. If the connection drops while waiting for the banner, the issue is likely network-related. If it fails after entering the password, focus on authentication services.
Check the server-side logs for clues. On most Linux distributions, these are found in
/var/log/auth.log or
/var/log/secure. Look for entries corresponding to your IP address around the time of the failure. Messages indicating "Connection closed by authenticating user" suggest the server terminated the session, possibly due to policy violations or resource limits. Conversely, if no log entry appears, the packet may be lost in transit.
Verifying Authentication Mechanisms
Even when using passwords, SSH relies heavily on underlying authentication agents and permission structures. Ensure that the SSH daemon configuration on the server allows password authentication. In
/etc/ssh/sshd_config, verify that
PasswordAuthentication yes is set. However, many modern systems prioritize key-based authentication, which can sometimes interfere with password prompts if keys are malformed.
If you have multiple SSH keys configured locally, the client might be trying invalid keys before falling back to the password prompt, causing delays or timeouts. You can specify a specific key using the
-i flag, such as
ssh -i ~/.ssh/id_rsa user@host. For environments managing complex identities, refer to our guide on
Managing Multiple SSH Keys on a Server to streamline identity resolution and prevent conflicts.
Check the permissions of your local private key file. The SSH client will refuse to use a key if its permissions are too open. Ensure the private key has read-only access for the owner by running
chmod 600 ~/.ssh/id_rsa. Similarly, check the
~/.ssh directory permissions, which should also be
700. Incorrect permissions do not always cause immediate rejection but can lead to intermittent behavior depending on the SSH client version and security policies.
Addressing Network and Timeout Issues
Intermittent connectivity is often a symptom of aggressive firewall rules or NAT (Network Address Translation) timeouts dropping idle connections. SSH sessions that appear active but carry no data may be silently dropped by intermediate routers. To mitigate this, configure keep-alive messages. Add the following lines to your local
~/.ssh/config file:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
This configuration sends a null packet every 60 seconds. If three consecutive packets fail, the client assumes the connection is dead and attempts to reconnect or report an error. This prevents the session from hanging indefinitely and helps distinguish between true disconnections and silent drops.
For servers behind heavy load balancers or strict firewalls, consider increasing the TCP keepalive settings on the server side as well. Edit
/etc/ssh/sshd_config and ensure
TCPKeepAlive yes is enabled. This allows the operating system to send keepalive signals at the TCP level, which some network devices recognize more reliably than application-level signals.
Checking Server Resources and Limits
If the server is under heavy load, it may drop new or existing connections to preserve stability. Check the number of open file descriptors and memory usage on the server. High CPU utilization can delay the processing of authentication requests, leading to client-side timeouts. Use commands like
top or
htop to monitor real-time resource consumption.
Additionally, verify that the maximum number of concurrent sessions has not been reached. In
/etc/ssh/sshd_config, the
MaxSessions directive limits the number of multiplexed channels per connection. While this rarely causes intermittent password failures, exhausting available PAM (Pluggable Authentication Modules) processes can. Check the PAM stack configuration in
/etc/pam.d/sshd to ensure no modules are failing silently.
For cases where the server becomes unreachable after extended periods, review our detailed analysis on
Ubuntu Server 22.04 Unreachable via SSH After Time: A Troubleshooting Guide to understand how background processes and cron jobs might impact SSH availability.
Frequently Asked Questions
Why does my SSH connection drop only after I enter the password?
This typically indicates that the authentication succeeded, but the session initialization failed. Common causes include incorrect shell paths in the user's profile, excessive startup scripts, or insufficient disk space on the home directory preventing the creation of temporary files.
How can I tell if the issue is on my client or the server?
Run
ssh -vvv on the client. If the verbose output stops progressing after the password prompt without further interaction, the issue is likely server-side. If the connection closes abruptly with a "Connection reset by peer" message, check your local network or firewall settings.
Does enabling two-factor authentication cause intermittent failures?
Two-factor authentication itself is reliable, but if the second factor requires a separate service (like a TOTP generator), network latency or service downtime can cause delays. Ensure your time synchronization is accurate on both client and server to prevent token validation errors.
What should I do if SSH works occasionally but fails most of the time?
This pattern strongly suggests a network layer issue, such as MTU mismatches or firewall state table exhaustion. Try reducing the MTU size on your interface or checking router logs for dropped packets. Also, verify that no VPN or proxy software is interfering with the SSH port.
Can corrupted host keys cause password authentication issues?
No, host key verification happens before password authentication. If host keys are corrupted or changed, SSH will warn you about a potential man-in-the-middle attack and refuse to connect entirely, never reaching the password prompt.