Keep ssh connection alive if internet briefly disconnects

Question

My employers wifi frequently drops for a few seconds. This will cause ssh sessions that I am not actively using to disconnect. Is there any way to keep the connection alive even the wifi briefly cuts out?

Answer 1

I also had this problem. Starting tmux sessions on the work servers, and then reconnecting to them after reestablishing the connection, let me pick up where I had left off with minimal annoyance.

Answer 2

On possible solution, depending on the destination of your ssh sessions and the rights you have on them is to have another interface on top of it, one that will not be brought down.

You can achieve that with a VPN. Either a full-fledged VPN (openvpn, wireguard, a commercial one) or one built on ssh and tun, for example.

End of the answer

Now, on to the way I set it up (there are many, many other):

In my case the interface now only goes down, it comes up with another public IP address every few hours. The sessions I care about belong to hosts on a single network, so my solution is a tunnel, with a tun device on my side, and another on the network I want to reach.

Just once, at boot for example, create the devices on each side (you need to be root):

ip tuntap add dev tun5 mode tun user youruser group yourgrup
ip address add 10.0.0.1/32 peer 10.0.0.2/32 dev tun5

(invert the addresses on the other side)

Then use the -w local_tun[:remote_tun] option (in this case -w 5:5) to connect normally from your host to the other host. You no longer need special permissions, because you created the tun devices for that user/group.

At this time you can ping between your hosts on the alternate addresses 10.0.0.x and you can set up policies, natting, routing and everything on your tun5 devices, as you would for any other network device.

So, what happens now when your link goes down? At that time the ssh session linking the two tun devices dies, but the tun devices themselves do not, they will just buffer data, and as soon as you connect again, traffic will resume.

Restarting the linking ssh session would be tedious and that's where autossh comes into play. It will restart that session whenever needed.

You just have to make sure the processes you want to survive the disconnect are using that interface (be it the IP, or a route, a NAT...). The whole setup might look overkill, but it works even with DDNS clients. After DNS catches up with the changes, the session is restablished and clients using the tun devices will resume.

Answer 3

Generally, TCP connections are stable against short disconnections - depending on the settings, but I think by default, TCP should survive at least 60s.

But that assumes that your IP address (/ that of the NAT'ing router) doesn't change. If that's not the case, that's not something TCP can deal with.

For such unreliable connections, there's a neat tool called mosh, and it excels at keeping an SSH connection alive through frequent reconnections, IP address changes and other disturbances.

It does that by implementing a different flow control protocol than TCP atop of UDP, and opening a UDP socket on the server. So, this requires your remote host to be able to open a UDP port, that's usually not a severe restriction.

Answer 4

You can try to setup ~/.ssh/config file

Host *
    ServerAliveInterval 10
    ServerAliveCountMax 60

A good explanation about what is each param, can be found here