You are here

ssh timeouts from home

If you work from home, you might find that your ssh sessions to the Informatics ssh servers unexpectedly time out. If so, the problem is almost certainly being caused by your home NAT router timing out what it considers to be an 'inactive' session.

The solution is to use 'ssh keepalives' - to configure your ssh client to automatically send some 'no-op' protocol codes to the server every now and again, in order that the NAT router considers the session to be active.

How to configure this will vary from OS to OS.

Linux and macOS

Add the following lines to your ~/.ssh/config file:

    Host *
      ServerAliveInterval 300

Note: create the ~/.ssh/config file if it doesn’t already exist, and make sure that it has permissions '600': that is, read/write for you, but not accessible by others.

For more details, man ssh_config.

Windows (PuTTY)

In your session properties, go to 'Connection' and under 'Sending of null packets to keep session active', set 'Seconds between keepalives (0 to turn off)' to 300.

See also

ssh_exchange_identification: read: Connection reset by peer

How does it work?

In TCP terms, the connection is defined by source address and port as well as destination address and port. When you connect from home your NAT box maps your laptop's local address and port to the external address it has been assigned by your ISP and to a port of its own choosing. That external address and port is what our login servers actually see. So long as your box maintains the mapping, and transforms the packets in both directions, your connection stays up.

The problem is that domestic NAT boxes generally have rather small NAT tables, and in order to keep these under control they tend to be rather agressive about timing out any mappings they think are idle. So if your ssh session sends no traffic (in either direction) then your box times out the mapping and throws away the table entry.

What happens when you then type something into your ssh shell? Your laptop sends a packet to the server through your NAT box, it sees that it has no mapping for the address/port, so it creates a new one. Unfortunately, that will generally be given a new external port. That packet, with the new port, hits our firewall, which doesn't see it as part of an existing connection (because the port is now different) so it drops the packet. Your end retries a few times, but this will inevitably be unsuccessful, and your ssh client then drops the connection.

What the keepalive code does is tell your client that it should send null packets to the other end every so often in the absence of any other activity. These are enough to persuade your NAT box that the session is still active, so it maintains the mapping.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
University services
Scheduled downtime

Choose a topic