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?

  • 2
    I use tmux and it works great when my ethernet fall Jun 8, 2021 at 21:51

4 Answers 4


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.


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 peer 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.

  • 1
    I like the VPN approach, but in all honesty, instead of using ssh+tun, to tunnel ssh through ssh, I'd recommend setting up Wireguard – that's as much part of modern kernels, and it's way easier to keep a tunnel through it alive. As said, it's part of the Linux kernel, and there's very well-working VPN clients for Android, Windows, … that really need but a minimum of setup. Jun 8, 2021 at 21:51
  • 1
    Yes, I have had this for ages and it's working. But there are other solutions. My answer is basically: use another interface on top of that. I'll change the answer to make it clearer (and see what it would take to migrate to Wireguard, if it would go through the firewalls along the way, deal with DDNS, etc.) Jun 8, 2021 at 21:54
  • Thank you for the kind words! You're right, there's more roaming-capable VPNs than sand in a camel's underwear, but I've been doing things very similar to you, and I was very much reminded of the relief I've felt when I discovered how easy wireguard becomes. :) I'm now very commonly forcing all my phone's traffic through my 4 lines of wireguard configuration on a server in a data center, so that I don't have to trust the operators of free Wifis. Jun 8, 2021 at 21:57

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.

  • A TCP connection can stay open a very long time without traffic, but the OP mentions actively used sesions. Those will not last if the interface they're based on is brought down. mosh, like autossh will restart the session, but the OP wants to keep the current session. Jun 8, 2021 at 22:01
  • mosh will not restart the session. Mosh uses a persistent single session that you reconnect to. Jun 8, 2021 at 22:19

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .