Keeping SSH Sessions Alive: A Practical Guide to Preventing Unexpected Timeouts

SSH disconnections are one of those small but frustrating issues that can easily interrupt your workflow. You're typing, running a long job, or just leaving a terminal open for a while — then suddenly everything freezes and the connection drops. Most of the time, this happens because of idle timeouts enforced either by the SSH server, the network in between, or even your own device.

This article explains, in a clear and practical way, how SSH timeouts work, why they happen, and how to configure your server so that your session stays alive for about five minutes of inactivity (or longer, if you choose). It also covers important considerations that many people overlook.

Why SSH Sessions Time Out

At a high level, an SSH connection can be terminated because of three major factors:

1. Server-side inactivity rules
   Most systems include SSH daemon parameters such as ClientAliveInterval and ClientAliveCountMax. If they’re not set correctly, the server will not send any keepalive messages, and your session may die quickly when idle.
2. Network or firewall behavior
   VPNs, corporate firewalls, cloud NAT gateways, and even some home routers aggressively remove idle TCP connections. If no packets flow for 30–60 seconds, they assume the session is dead.
3. Client-side timeouts
   Your SSH client may also have its own keepalive mechanisms. If these aren't enabled, it won’t try to revive an idle connection.

Understanding these layers helps you tune your setup to achieve the stability you want.

Configuring SSH for a Five-Minute Idle Timeout

If you want your SSH session to remain alive for approximately 5 minutes, the most reliable approach is configuring the server to send keepalive messages at predictable intervals.

Edit your SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Set:

ClientAliveInterval 60
ClientAliveCountMax 5

What These Settings Mean

• ClientAliveInterval 60
  The server will send a keepalive packet every 60 seconds to ensure the session is still active.
• ClientAliveCountMax 5
  If the client fails to respond five times in a row, the server will terminate the session.

Together:

60 seconds × 5 = 300 seconds
→ exactly 5 minutes of tolerated inactivity

This configuration is stable, predictable, and widely used in production environments.

After editing the file:

sudo systemctl restart sshd

Situations Where You Need a More Aggressive Approach

In some environments — especially cloud platforms — you may discover that connections still die too quickly. This usually happens because NAT gateways or firewalls drop idle connections after 30 seconds of inactivity.

If that’s your situation, adjust the settings to send keepalives more frequently:

ClientAliveInterval 30
ClientAliveCountMax 10

This still gives you a five-minute window, but with check-ins every 30 seconds, making it less likely for external network devices to prematurely terminate the session.

Strengthening the Client-Side Configuration

Although server-side settings do most of the work, you can improve stability by instructing the SSH client to send its own heartbeat signals.

Edit:

nano ~/.ssh/config

Add:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 5

Client keepalives help especially if:

• You often connect from laptops on Wi-Fi
• You're behind corporate networks
• You switch networks mid-session

These small touches can significantly reduce disconnects.

Using tmux or screen for Long-Running Sessions

Even with optimal timeout settings, you should never rely solely on SSH for protecting long-running processes. Tools like tmux and screen allow your session to persist even if your SSH connection drops unexpectedly.

Start a session:

tmux

Then attach again if disconnected:

tmux attach

This is essential for:

• Background jobs
• Deployments
• Database imports
• Remote editing

It prevents losing work due to network instability.

Other Important Considerations You May Be Missing

1. Systemd Idle Timeouts

Some distributions enforce additional idle rules beyond SSH. If the OS itself kills idle sessions, you must override logind.conf.

2. VPN Behavior

Corporate VPNs often enforce strict idle thresholds. Keepalives help, but sometimes the VPN will still enforce hard limits.

3. Power Settings on Laptops

If your Wi-Fi card enters low-power mode, it may drop the connection. This can feel like an SSH timeout even though the server is fine.

4. Cloud Environment Quirks

AWS, Azure, and GCP NAT timeouts differ. Some aggressively kill idle connections unless packets are exchanged every 15–30 seconds.

5. Multi-Hop SSH

If you use ProxyJump or SSH tunnels, remember each layer (client → jump host → destination) may require its own keepalive tuning.

Finally

To maintain an SSH session for five minutes of idle time, the most reliable configuration is:

• For true stability: use tmux so your work continues even if SSH disconnects.

If your network is unstable or cloud NAT is aggressive:

ClientAliveInterval 30
ClientAliveCountMax 10

Client-side (optional):

ServerAliveInterval 60
ServerAliveCountMax 5

Server-side:

ClientAliveInterval 60
ClientAliveCountMax 5

By understanding how SSH timeouts work and tuning both sides, you create a far more reliable and predictable remote-working environment — one where unexpected disconnects stop being part of your daily routine.

Support Us

Share to Friends