How to Keep SSH Session Alive

SSH (Secure Shell) is a crucial tool for system administrators and developers who need to access and manage remote servers securely. However, one common frustration is having your SSH connection terminate unexpectedly due to inactivity, leaving you to reconnect and potentially lose unsaved work or interrupt ongoing processes. These disconnections typically occur due to network timeouts, NAT firewalls, or server security policies that automatically close idle connections.

In this comprehensive guide, we’ll explore various methods to keep your SSH sessions alive and prevent these unwanted disconnections. Whether you’re managing production servers, working on development environments, or simply accessing your personal remote machines, these techniques will help maintain stable and reliable SSH connections.

Table of Contents

Understanding SSH Timeout Behavior

Before diving into solutions, it’s important to understand why SSH sessions disconnect in the first place. This knowledge will help you choose the most appropriate method for your specific situation.

Why SSH Sessions Disconnect

SSH connections often terminate due to intermediary network devices like NAT firewalls that are designed to clean up idle connections. Many commodity firewalls automatically drop connections after as little as 300 seconds (5 minutes) of inactivity. This behavior is intended to conserve network resources and maintain security, but it can be inconvenient when you need to maintain long-running sessions.

Additionally, network instability, router configurations, and ISP policies can all contribute to SSH session terminations. When data stops flowing through the connection, various points along the network path may assume the connection is no longer needed and close it accordingly.

SSH Keepalive vs. TCP Keepalive

There are two primary mechanisms for maintaining connections: SSH keepalive and TCP keepalive. Understanding the difference is crucial:

SSH keepalive operates at the application layer and sends packets through the encrypted SSH channel. This makes it more secure as these packets cannot be spoofed. SSH keepalive is specifically designed to maintain the SSH connection regardless of the underlying TCP connection status.

TCP keepalive, on the other hand, works at the transport layer and is more general-purpose. It’s part of the TCP protocol itself and can be spoofed. While it can help maintain the TCP connection, it doesn’t provide the same level of security or reliability for SSH specifically.

For most SSH use cases, SSH keepalive is the preferred method because it works within the secure SSH protocol and provides better control over connection maintenance.

Client-Side Configuration Methods

One of the simplest and most effective ways to prevent SSH disconnections is to configure your SSH client to send periodic keepalive messages. Here are different approaches based on your system and needs.

Configuring SSH Client Config Files

For Linux, macOS, and Unix-like systems, you can configure the SSH client to automatically send keepalive packets:

1. Create or edit your SSH config file:

nano ~/.ssh/config

2. Add the following lines to keep all SSH connections alive:

Host *
    ServerAliveInterval 120
    ServerAliveCountMax 2

These settings tell your SSH client to send a null packet to the server every 120 seconds and to disconnect if it doesn’t receive a response after 2 attempts. You can adjust these values based on your needs:

ServerAliveInterval: Sets the time in seconds between keepalive packets (recommended range: 30-300 seconds)
ServerAliveCountMax: Determines how many consecutive unanswered keepalive messages are permitted before the client disconnects (typical values: 2-3)

For even more aggressive keepalive settings, some users prefer:

ServerAliveInterval 30
ServerAliveCountMax 2

This configuration sends a keepalive every 30 seconds and gives up after 60 seconds of no response, which works well for less stable connections.

Command-Line Options for One-Time Sessions

If you don’t want to modify your config file or need a one-time solution, you can specify keepalive parameters directly on the command line:

ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@hostname

This approach is useful when you need different keepalive settings for specific connections or when you’re using a system where you can’t modify the SSH config file.

GUI SSH Clients Configuration

For Windows users or those who prefer graphical interfaces, popular SSH clients like PuTTY also offer keepalive options:

In PuTTY, load your session or start a new one
Navigate to Connection in the category tree
Under “Sending of null packets to keep session active,” set “Seconds between keepalives” to a value like 300
Save your session settings if desired

This configuration will send a null packet every 5 minutes (300 seconds), which is sufficient to keep most connections alive.

For other GUI clients, look for similar options in connection or preferences settings, often labeled as “keepalive,” “heartbeat,” or “connection timeout” features.

Server-Side Configuration Methods

While client-side configuration is often sufficient, there are scenarios where server-side settings are preferable, especially when managing multiple clients connecting to the same server.

Editing the SSH Server Configuration

To configure keepalive at the server level:

1. Edit the SSH daemon configuration file (requires root/sudo privileges):

sudo nano /etc/ssh/sshd_config

2. Add or modify the following lines:

ClientAliveInterval 300
ClientAliveCountMax 2

3. Save the file and restart the SSH service:

sudo systemctl restart sshd

or on older systems:

sudo service ssh restart

These settings instruct the SSH server to check if the client is still responsive by sending a message every 300 seconds (5 minutes). If the client fails to respond to 2 consecutive messages, the server will disconnect the session.

With these settings, an unresponsive client would be disconnected after approximately 600 seconds (10 minutes), providing a good balance between keeping legitimate sessions alive and cleaning up abandoned connections.

When to Use Server-Side vs. Client-Side Settings

Server-side configuration is ideal when:

You manage a server with many users and want consistent behavior
Your clients connect from various systems with different SSH client implementations
You need to enforce specific timeout policies across all connections

Client-side configuration is preferable when:

You don’t have administrative access to the server
You need different keepalive settings for different servers
You want to maintain control over your connection behavior regardless of server settings

For optimal results, you can implement both client and server-side configurations. When both are configured, the more aggressive setting (shorter interval) typically takes precedence, ensuring connections remain active.

Using Terminal Multiplexers

Terminal multiplexers provide a different approach to the problem by allowing sessions to persist independently of the SSH connection. This means you can detach from a session, have your SSH connection drop, and later reconnect to the same session with all your work intact.

The Screen Command

Screen is a widely available terminal multiplexer that comes pre-installed on many Linux distributions:

1. Install screen if not already available:

sudo apt-get install screen    # Debian/Ubuntu
sudo yum install screen        # CentOS/RHEL

2. Start a new screen session:

screen

3. Use the session normally for your work

4. To detach from the session (leaving it running in the background):

Press Ctrl-a followed by d

5. To reattach to an existing session later:

screen -r

If you have multiple screen sessions, you’ll need to specify which one to reattach to:

screen -ls            # List all available sessions
screen -r [session_id]  # Reattach to a specific session

Common screen commands include:

Ctrl-a c: Create a new window
Ctrl-a n: Move to the next window
Ctrl-a p: Move to the previous window
Ctrl-a ?: Show help with all commands

Screen sessions persist even when your SSH connection terminates, allowing you to resume exactly where you left off.

Using Tmux as an Alternative

Tmux is a more modern terminal multiplexer with additional features and an active development community:

1. Install tmux:

sudo apt-get install tmux    # Debian/Ubuntu
sudo yum install tmux        # CentOS/RHEL

2. Start a new tmux session:

tmux

3. Basic tmux commands:

Ctrl-b d: Detach from the current session
Ctrl-b c: Create a new window
Ctrl-b p: Switch to the previous window
Ctrl-b n: Switch to the next window
Ctrl-b %: Split the current pane vertically
Ctrl-b ": Split the current pane horizontally

4. To reattach to a detached session:

tmux attach

5. For multiple sessions:

tmux ls                     # List all sessions
tmux attach -t [session_name]  # Attach to a specific session

Tmux offers advantages over screen including better window splitting, a status bar with session information, and more customization options through its configuration file (~/.tmux.conf).

Both screen and tmux allow you to maintain persistent sessions regardless of SSH connection status, making them invaluable tools for remote work.

Advanced Techniques

For users with more complex needs, several advanced techniques can provide additional reliability and functionality beyond basic keepalive mechanisms.

Using Persistent SSH Connections

SSH’s ControlMaster feature allows multiple SSH sessions to share a single network connection, reducing connection overhead and allowing new sessions to remain active even if the original connection drops:

1. Configure your SSH client by adding these lines to ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/control:%h:%p:%r
    ControlPersist 4h

2. This configuration:

Automatically creates a master connection when you connect to a server
Stores connection information in a socket file
Keeps the master connection alive for 4 hours after your last session closes

Subsequent SSH connections to the same server will use the existing connection, making them faster to establish and more resilient against temporary network issues.

Autossh for Connection Monitoring and Restoration

Autossh is a utility that monitors SSH connections and automatically restarts them if they drop:

1. Install autossh:

sudo apt-get install autossh    # Debian/Ubuntu
sudo yum install autossh        # CentOS/RHEL

2. Basic usage:

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" user@hostname

The -M 0 parameter disables autossh’s built-in monitoring and relies on SSH’s own keepalive mechanism, which is generally more reliable.

Autossh can also be used with port forwarding:

autossh -M 0 -f -N -L 8080:localhost:80 user@remote-server

This maintains a persistent port forwarding tunnel that automatically reconnects if the connection drops.

Mosh (Mobile Shell) as an SSH Alternative

Mosh is designed specifically for mobile or unreliable network connections:

1. Install mosh on both client and server:

sudo apt-get install mosh    # Debian/Ubuntu
sudo yum install mosh        # CentOS/RHEL

2. Connect using mosh instead of ssh:

mosh user@hostname

Mosh differs from SSH in several important ways:

It maintains the connection even when your IP address changes
It provides immediate local echo of keystrokes
It works well with intermittent connectivity
It automatically reconnects without user intervention

Many users find that mosh provides a significantly better experience on unreliable networks or when frequently switching between networks.

Troubleshooting Common Issues

Even with the best configurations, SSH connection issues can still occur. Here are solutions to common problems:

Diagnosing Connection Problems

If you’re experiencing SSH disconnections despite implementing keepalive settings:

1. Check your logs for timeout messages:

grep "timeout" /var/log/auth.log    # On the SSH server

2. Test connectivity with verbose logging:

ssh -vvv -o ServerAliveInterval=30 user@hostname

Look for messages related to keepalive packets and responses.

3. Use network diagnostic tools to identify potential issues:

mtr hostname    # Combines ping and traceroute functionality

4. Verify that SSH traffic isn’t being blocked by firewalls:

telnet hostname 22    # Should connect successfully if SSH port is open

Fixing Issues with Different Keepalive Methods

If your keepalive settings aren’t working:

1. Verify that your configuration files are in the correct location and have proper permissions:

ls -la ~/.ssh/config               # Client config
sudo ls -la /etc/ssh/sshd_config   # Server config

2. Test with more aggressive settings temporarily:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=2 user@hostname

3. If using mosh, ensure UDP ports 60000-61000 are open in firewalls.

4. For screen or tmux issues, check that the programs are installed correctly and that you have appropriate permissions.

Common configuration mistakes include:

Syntax errors in config files
Incorrect permissions (SSH is particular about file permissions)
Conflicting settings at different levels (system-wide vs. user-specific)
Server firewalls blocking keepalive packets

Best Practices

To maintain secure and reliable SSH connections, follow these recommended practices:

Security Considerations

While keepalive mechanisms improve usability, they should be implemented with security in mind:

1. Use reasonable keepalive intervals:

Too frequent (under 10 seconds): Increases network traffic and server load
Too infrequent (over 10 minutes): May not prevent timeouts
Recommended: 30-300 seconds depending on network reliability

2. Implement key-based authentication instead of passwords:

ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id user@hostname

3. Consider additional security measures:

Limiting SSH access to specific IP addresses
Using fail2ban to prevent brute force attacks
Enabling two-factor authentication for SSH

Remember that any persistent connection represents a potential security risk if your local machine is compromised, so always lock your computer when stepping away.

Performance Optimization

Optimize your SSH configuration for both performance and reliability:

1. Balance keepalive frequency with network overhead:

Lower values increase reliability but generate more network traffic
Higher values reduce overhead but may not catch all timeout conditions

2. Use compression for slow connections:

ssh -C user@hostname    # Enable compression

Or add to your SSH config:

Host slow-connection
    Hostname example.com
    Compression yes

3. Optimize terminal multiplexer configurations:

For screen, consider adding to ~/.screenrc:

autodetach on
startup_message off
vbell off
defscrollback 10000

For tmux, optimize ~/.tmux.conf:

set -g history-limit 10000
set -g status-interval 60

These optimizations will help maintain reliable connections while minimizing unnecessary network traffic and server load.

Integration with Other Tools and Workflows

SSH session persistence can be integrated into broader workflows and automation systems for maximum efficiency.

SSH Keepalive in Scripts and Automation

When incorporating SSH into scripts or automated tasks:

1. Include keepalive options in scripts that use SSH:

#!/bin/bash
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@hostname "long-running-command"

2. For scheduled jobs, consider using a combination of SSH keepalive and terminal multiplexers:

#!/bin/bash
# Create a detached screen session that runs a task
ssh user@hostname "screen -dmS task_name /path/to/script.sh"

# Later, check the results
ssh user@hostname "screen -r task_name -X hardcopy /tmp/output.txt"
scp user@hostname:/tmp/output.txt ./local_output.txt

3. Use environment variables to standardize SSH options across scripts:

export SSH_OPTS="-o ServerAliveInterval=60 -o ServerAliveCountMax=3"
ssh $SSH_OPTS user@hostname

SSH Session Management for DevOps Workflows

In DevOps environments, maintaining reliable SSH connections is crucial:

1. Configure CI/CD systems with appropriate keepalive settings:

# Example for GitHub Actions
steps:
  - name: Deploy via SSH
    run: |
      mkdir -p ~/.ssh
      echo "Host *
        ServerAliveInterval 60
        ServerAliveCountMax 3" > ~/.ssh/config
      ssh user@hostname "./deploy.sh"

2. For container environments, persistent connection settings should be baked into base images:

# In Dockerfile
RUN mkdir -p /etc/ssh
COPY ssh_config /etc/ssh/ssh_config

3. Consider using SSH bastion hosts for complex environments:

Host internal-server
    ProxyJump bastion-host
    ServerAliveInterval 30
    ServerAliveCountMax 3

These integration strategies ensure that your SSH connections remain reliable throughout your entire workflow, from development to deployment and monitoring.

VPS Manage Service Offer

If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal!