Why SSH sessions drop on mobile networks and what to set

SSH sessions drop on mobile networks because the connection is tied to one network path. When your phone or laptop changes network, or a middlebox forgets an idle connection, the session breaks. The sshd settings ClientAliveInterval and ClientAliveCountMax help the server notice dead clients and free them.

Two different problems

People lump all dropped sessions together, but there are two causes with different fixes.

1. The session is idle and something in the path forgets it. Home routers and mobile carriers keep tables of open connections and discard quiet ones. You come back to a frozen terminal.
2. The client moved. You switched from Wi-Fi to cellular, the address changed, and the old connection can never carry traffic again. The server does not know, so it keeps a dead session open.

A keepalive fixes the first. A timeout that cleans up dead sessions fixes the second. They are set in different places.

What the server setting does

The OpenBSD man page for sshd_config describes ClientAliveInterval as the number of seconds of client inactivity before sshd sends an encrypted message requesting a response. The default is 0, meaning no messages are sent. ClientAliveCountMax has a default of 3. With an interval of 15 and the default count, unresponsive clients are disconnected after about 45 seconds.

Two points follow from that.

• The probe is encrypted and goes through the same connection, so it also keeps many idle-forgetting devices from discarding the session.
• The disconnect closes sessions where the client has vanished, so you do not accumulate ghost logins that look active in the server's list.

A cautious starting point

ClientAliveInterval 30
ClientAliveCountMax 3

That drops a silent client after roughly 90 seconds. Shorter intervals notice sooner but also cut off people on very poor links. Pick a value that matches how your team works, and test it from a phone hotspot.

For the client side, OpenSSH has a matching option on the client that sends probes from your end, which is the right tool if the problem is your own router forgetting idle connections. Check your client's documentation for the exact name and defaults.

Keepalive is not the same as an idle timeout

This matters for security. A keepalive probe keeps a connection alive, and it does not log you out after inactivity. A session that has a shell open and responds to probes can sit forever. If you want a user-level idle limit, use a separate control, such as a shell timeout or a session policy. See how long a remote session should last.

In short: ClientAlive settings clean up dead connections. They do not enforce human inactivity.

Roaming without losing work

If you work from a phone or a train, a plain SSH session is fragile. Practical options:

• Run long work inside a terminal multiplexer on the server, so a dropped connection leaves the job running and you can reattach.
• Keep long jobs out of the interactive session altogether. Use a build system, scheduled job or CI run.
• Use a tool built for roaming sessions if your policy allows one, and review its security model before you adopt it.

Security checks that go with it

Keepalive changes are small, but while you are in the file, review the rest. Our guide to sshd settings to check before you SSH in from anywhere lists six that matter more.

Quick check

Sources

• OpenBSD manual: sshd_config

Last reviewed: 19 October 2026.