Fixing SSH timeout problems

This post is about resolving ssh idle timeout issues.

Foreword

Using SSH to connect to a remote unix host is invaluable, but most users are frustrated by the default behaviour where sessions left idle for a short time are automatically disconnected. Here I'll talk about some strategies for overcoming this.

Preventing auto SSH disconnection on the server.
This strategy involves adjusting the configuration of the server's ssh daemon, so you'll need root access to the server for this.
The ssh daemon is the server side service that allows ssh connections to be made, we can configure it by adjusting it's configuration file:

vi  /etc/ssh/sshd_config

locate the line:
#ClientAliveInterval 0
and modify it to:

ClientAliveInterval 60

Save the file.
Reload the new sshd config with:
service sshd reload

This adjustment causes the server to send a keep-alive message to the client every 60 seconds. As long as your client is still connected this is enough to prevent the connection from being idle and closing.
The default value of 0 meant that no keep-alive message was ever sent and your connection dies from being idle.

Read more at
man sshd_config

Preventing auto SSH disconnection on the client.

Linux/Unix Clients
Similar to the server side strategy presented above, here we adjust the ssh client configuration so it sends the keep-alive message to the server every 60 seconds.

vi  /etc/ssh/ssh_config

locate the line:
#ClientAliveInterval 0
and modify it to:

ClientAliveInterval 60

Save the file.

Windows Clients
Most windows users use PuTTY , probably because it's free ;-)

PuTTY Settings -> Connection

Set PuTTY to send keep-alive messages every 60 secs (as shown above).

Other Strategies

If you don't fancy any of the above, when you know you're going to leave your ssh connection idle for some time simply issue the top command:

top

This starts the interactive top program that auto refreshes your server state every few seconds and will be enough to stop a timeout. Hit q to exit top.


Conclusion
All strategies presented above achieve the same goal. The method you choose will largely be determined by whether you have root access to the server and whether you want changes to affect all clients connecting to the server.