ServerAliveInterval and ServerAliveCountMax to your local %USERPROFILE%/.ssh/config file, you can ensure that the connection remains active even when no data is being transferred. This simple configuration prevents network intermediaries from timing out your session, allowing for uninterrupted work on your Linux system without the frustration of re-authenticating or losing your place in a long-running process.
Understanding Why SSH Sessions Disconnect
Network connections are not permanent; they rely on stateful tracking by routers, firewalls, and NAT devices along the path between your computer and the remote server. When a TCP connection sits idle for a certain duration, these intermediate devices often assume the connection is dead and drop it to free up resources. This behavior is standard across most internet infrastructure, meaning that even if your local machine and the remote server both have infinite timeouts set, the middleman will still cut the cord.
The Secure Shell (SSH) protocol itself does not automatically send traffic during idle periods unless explicitly configured to do so. Without periodic "heartbeat" signals, the network sees silence and terminates the socket. This is particularly problematic for developers who leave terminals open while working on other tasks, or for users running long compilation jobs where background output might be sparse. The solution lies in making the client proactively maintain the connection status by sending small packets through the existing channel.
Configuring the Client-Side Solution
The most effective way to handle this issue is by modifying your local SSH client configuration rather than asking the remote administrator to change server settings. This approach gives you control over your own sessions and works regardless of the remote host's policy. You should edit the configuration file located at %USERPROFILE%/.ssh/config on Windows or ~/.ssh/config on Unix-like systems. If the file does not exist, you can create it with appropriate permissions.
Inside this file, you can define global settings or host-specific rules. To apply these settings universally to all your connections, use the Host * directive. This acts as a wildcard that matches every hostname you connect to. Within this block, you will add three key parameters that dictate how the keepalive mechanism functions.
The ServerAliveInterval Parameter
The ServerAliveInterval setting determines how frequently the client sends a request to the server to check if the connection is still alive. The value is specified in seconds. For example, setting ServerAliveInterval 60 tells the SSH client to send a keepalive message every 60 seconds. A common recommendation is to use a value between 30 and 120 seconds, depending on your tolerance for bandwidth usage versus connection stability. Sending messages too frequently might be unnecessary overhead, while waiting too long increases the risk of the connection being dropped before the client can react.
The ServerAliveCountMax Parameter
While ServerAliveInterval sets the frequency, ServerAliveCountMax defines the threshold for failure. It specifies the maximum number of keepalive messages that may be sent without receiving any response from the server before the client disconnects. If you set ServerAliveCountMax 3, the client will wait for three consecutive intervals (e.g., 180 seconds if the interval is 60) without hearing back before terminating the session. This prevents the client from hanging indefinitely if the server becomes unresponsive but the network link is still technically up.
Implementation Steps
To implement this fix, follow these concrete steps to update your configuration safely:
- Locate the Config File: Navigate to your user profile directory and find the
.sshfolder. Ensure theconfigfile exists. On Windows, this is typicallyC:\Users\YourUsername\.ssh\config. - Edit the File: Open the file in a plain text editor. Do not use rich text editors like Microsoft Word, as they may introduce formatting characters that break SSH parsing.
- Add the Host Block: Add the following lines to the bottom of the file:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3This configuration ensures that for every host you connect to, the client checks in every minute and allows for three missed responses before giving up. After saving the file, you must close any existing SSH sessions for the changes to take effect. New connections initiated after the save will automatically inherit these parameters.
Verifying the Configuration
Once you have updated the config file, it is prudent to verify that the client is actually using the new settings. You can do this by initiating a test connection with verbose output. Run the command ssh -v username@hostname and look for lines indicating keepalive activity. Alternatively, you can check the effective configuration by running ssh -G username@hostname | grep serveralive. This command dumps the final resolved configuration values, allowing you to confirm that serveraliveinterval and serveralivecountmax reflect your intended values.
If you encounter issues with authentication, such as permission denied errors, remember that client-side keepalives do not fix underlying access problems. For guidance on resolving authentication failures, you might refer to our guide on Fixing Permission Denied with OpenSSH. Similarly, if you are setting up complex environments like MPI jobs, ensuring stable connections is crucial, and you may want to review Enabling Passwordless SSH Access for Running MPI jobs on Two Nodes to streamline your workflow further.
Frequently Asked Questions
Does this setting affect server load?
No, the impact is negligible. The keepalive packets are extremely small, consisting only of a few bytes of header information. They consume virtually no bandwidth and processing power on the remote server, making them safe for high-traffic production environments.
Can I set different intervals for specific hosts?
Yes, you can override the global settings by creating a new Host block with a specific pattern. For example, you can set a shorter interval for unstable networks by specifying Host unstable-server followed by its own ServerAliveInterval value, which will take precedence over the global wildcard.
What if the server rejects the keepalive messages?
Standard SSH servers accept these internal protocol checks without issue. However, if you are connecting through a strict firewall or proxy that inspects traffic, ensure that outbound TCP port 22 is allowed. If you see a kex_exchange_identification error, it may indicate a deeper network routing problem unrelated to idle timeouts, which you can troubleshoot using our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection.
Is there a command-line alternative to editing the config file?
Absolutely. You can pass these options directly in your SSH command line instead of editing the file. Use flags like -o ServerAliveInterval=60 -o ServerAliveCountMax=3 followed by your usual connection arguments. This is useful for one-off sessions or temporary troubleshooting.
Will this prevent my screen from turning off?
No, this setting only maintains the network socket between your local machine and the remote server. It does not control local display sleep settings or terminal multiplexer screens like tmux or screen. You should still use those tools to protect your work from local hardware sleep modes.