139

I have ServerAliveInterval and in case of few machines also ClientAliveInterval set to 540 in SSH client/server configuration files (I suppose setting it to more than that would not be a good idea). I work with many SSH sessions which currently freeze after a few minutes.

How can I fix it? What I want is to have a session to not freeze at all, so that if I open a session at 8 and don't use it for 4 hours, for example, to still use it again at 12 without having to log-in again.

Improve this question
6
  • How long can you currently stay logged in (assuming this isn't due to network disconnection)? TCPKeepAlive yes?
    – iyrin
    Commented May 4, 2015 at 8:40
  • 12
    Just use mosh?
    – Vi.
    Commented May 4, 2015 at 11:08
  • 2
    Or you could use autossh...
    – ThoriumBR
    Commented May 4, 2015 at 18:24
  • 3
    I'd say leaving a connection open for 4 hours is a security concern, and you should be using screen instead. But I'm still upvoting your question because I'm experiencing the same issue after only a minute or two.
    – Dale C. Anderson
    Commented Aug 24, 2016 at 17:22
  • 1
    Related: superuser.com/q/37738
    – user6860
    Commented Dec 29, 2017 at 16:28

10 Answers 10

Reset to default
170

The changes you've made in /etc/ssh/ssh_config and /etc/ssh/sshd_config are correct but will still not have any effect.

To get your configuration working, make these configuration changes on the client:

/etc/ssh/ssh_config

Host *
ServerAliveInterval 100

ServerAliveInterval The client will send a null packet to the server every 100 seconds to keep the connection alive

NULL packet Is sent by the server to the client. The same packet is sent by the client to the server. A TCP NULL packet does not contain any controlling flag like SYN, ACK, FIN etc. because the server does not require a reply from the client. The NULL packet is described here: https://www.rfc-editor.org/rfc/rfc6592

Then configuring the sshd part on the server.

/etc/ssh/sshd_config

ClientAliveInterval 60
TCPKeepAlive yes
ClientAliveCountMax 10000

ClientAliveInterval The server will wait 60 seconds before sending a null packet to the client to keep the connection alive

TCPKeepAlive Is there to ensure that certain firewalls don't drop idle connections.

ClientAliveCountMax Server will send alive messages to the client even though it has not received any message back from the client.

Finally restart the ssh server

service ssh restart or service sshd restart depending on what system you are on.

Improve this answer
14
  • I think a high ServerAliveCountMax is also needed in order for this to be as reliable as possible. And if both ServerAliveInterval and ClientAliveInterval are set low enough, I don't think there will be any need for TCPKeepAlive. Additionally, if there are any middleboxes, they can still lose state even with all of the previously mentioned settings configured exactly correct. It may help to use MPTCP (if both client and server support it).
    – kasperd
    Commented May 4, 2015 at 20:28
  • It's not clear at the start whether you mean config on the client side or server side (eventually I conclude, client side). Then at ServerAliveInterval description, you say "client will send... to the server", but in the next paragraph "NULL packet is sent by the server to the client". I find these a bit confusing.
    – Craig McQueen
    Commented Jun 11, 2017 at 7:23
  • 1
    After adding to the server I get: /etc/ssh/ssh_config: line 57: Bad configuration option: clientaliveinterval /etc/ssh/ssh_config: line 59: Bad configuration option: clientalivecountmax
    – ajthinking
    Commented Jul 29, 2017 at 15:57
  • 6
    @Anders You get the error because ClientAliveInterval and ClientAliveCountMax are ssh server options, thus meant for sshd_config and not ssh_config
    – Valentin Bajrami
    Commented Jul 30, 2017 at 8:11
  • 2
    @chandresh you don't have to. After modifying ssh_config the new sessions will read that file. The /etc/environment file is a different thing which has the format of VAR="value" without spaces thus VAR = "value" would be invalid. Sourcing /etc/ssh/ssh_config that way will i.e read: Port 22 or Host * which will treat these as commands
    – Valentin Bajrami
    Commented Aug 14, 2019 at 12:38
16

Personal suggestion: use screen on the remote host; it will manage to keep your connection alive for as long as it stays active in a terminal.

Here's what I typically add to /etc/screenrc for quick identification of my screen sessions:

hardstatus alwayslastline
hardstatus string "%{= kG}[ %{G}%H %{g}][ %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]"
defscrollback 8192

EDIT : Hints.

The hardstatus string will show a bottom status line such as this one: Screen session example with three open tabs

The scrollback buffer is also extended to 8192 lines instead of the usual 1000-1500 (depending on the distribution).

Improve this answer
4
  • Thanks, two questions: 1. Can you explain the options in you screenrc file? How do I configure the system the launch screen/tmux right after I login?
    – syntagma
    Commented May 4, 2015 at 9:12
  • 14
    Just to clarify, screen does not keep your ssh connection alive. It runs processes in a virtual terminal independent of the user terminal you connect to via ssh so the process doesn't rely on your connection. You will still lose your ssh connection until it's resolved.
    – iyrin
    Commented May 4, 2015 at 9:52
  • 1
    By "keep the connection alive" I essentially mean "prevents the connection from idling", which has the same result. If there's no input for 4 hours, SSH will go idle and eventually close the connection, all the child processes gone, too.
    – user86969
    Commented May 4, 2015 at 11:46
  • 5
    As much as I loved screen, I advise new users to start with tmux.
    – dotancohen
    Commented May 5, 2015 at 7:10
7

If the problem is a hibernated laptop or a less-than-prefect network connection, I'd recommend using mosh which runs over ssh and allows automatic reconnecting.

From the website:

Mosh (mobile shell)

Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh is free software, available for GNU/Linux, BSD, macOS, Solaris, Android, Chrome, and iOS.

In combination with tmux (or the older screen), this allows me to connect via ssh to a server from my laptop and stay connected for days even when changing wifi connections and surviving mobile data drop-outs.

Improve this answer
2
  • Here is a link to mosh.org and to mosh on Github
    – joeytwiddle
    Commented Oct 26, 2017 at 2:10
  • this feels like the way ssh should be in 2022 - I wonder why this is not more of a thing
    – ErichBSchulz
    Commented Sep 14, 2022 at 5:20
2

With OpenSSH:

You need to enable 

TCPKeepAlive yes

both in your client ssh_config (e.g. /etc/ssh/ssh_config or in ~/.ssh/config) and your destination SSH server running OpenSSH (e.g. /etc/ssh/sshd_config).

So every time your connection idles, OpenSSH sends some dummy packet to your destination host...

Improve this answer
2
  • This can also cause the connection to go down The default is ''yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. ...this means that connections will die if the route is down temporarily, and some people find it annoying. linux.die.net/man/5/sshd_config
    – iyrin
    Commented May 4, 2015 at 8:55
  • Honestly, but "[…] network goes down […] client host crashes […] route is down […]" are severe errors no SSH configuration can catch. The main issue here are idle SSH sessions, not network failures. Therefore to sum it up: - enable TCPKeepAlive yes in both server and client. - set ClientAliveInterval on the server - set IdleTimeout on the server - set ClientAliveCountMax That should do the trick...
    – Martin Allert
    Commented May 4, 2015 at 9:48
1

Check your sshd configuration on the host machine /etc/sshd_config for the IdleTimeout setting. 

IdleTimeout time
Sets idle timeout limit to time in seconds (s or nothing afternumber), 
in minutes (m), in hours (h), in days (d), or in weeks (w).If the 
connection have been idle (all channels) for that long time thechild 
process is killed with SIGHUP, and connection is closed down.
Improve this answer
1

A little hack I use if it's not possible to use screen, or edit the hosts ssh server settings, or any of the good and proper suggestions above...

Just run top whenever you are going to leave the session alone.

Generally that'll keep it alive indefinitely, although, as others have mentioned, that might not always be wise vis-a-vis security!

Improve this answer
1

For me, the SSH connection used to hang up.

The below solution worked for me. Now the SSH connection always stays live.

From the server:

  1. Edit the file at /etc/ssh/sshd_config
$ sudo vi /etc/ssh/sshd_config
  1. Add or enable this line in the file.
ClientAliveInterval 60
  1. Save the file and restart the sshd service
$ sudo service sshd restart

From the local machine/client:

  1. Edit the file at /etc/ssh/ssh_config
$ sudo vi /etc/ssh/ssh_config
  1. Add this line to the file.
ServerAliveInterval 60
  1. Save the file

About these Parameters :

ServerAliveInterval: number of seconds that the client will wait before sending a null packet to the server (to keep the connection alive).

ClientAliveInterval: number of seconds that the server will wait before sending a null packet to the client (to keep the connection alive).

Important: Whenever any modification is performed on a Production instance, please ensure to create a backup.

Improve this answer
1
  • 2
    This is in essence the same as accepted solution.
    – ibuprofen
    Commented Jun 15, 2021 at 14:55
1

I had a similar problem:

  • ssh connection remained ESTABLISHED
  • terminal freezes and un-freezes repeatedly
  • packets are visible in SEND-Q while terminal freezes
  • freeze time about 2-4 minutes
  • un-frozen for about 30 seconds

Turns out the firmware of my router was outdated!

  • fixed issue with firmware update
Improve this answer
0

In my case problem was in large MTU size. You can change MTU on router if you using NAT, but I change MTU on server:

sudo /sbin/ifconfig eth0 mtu 1036
sudo /etc/init.d/networking restart
Improve this answer
0

My SSH started closing consistently after a minute of being open and I think it was because of a network adapter setting I changed in order to stop my PC from waking up from sleep. My PC had been waking up from sleep for no reason so I found this article on how to stop it and it worked. The article said to go into the Device Manager, find the Ethernet or Wi-Fi adapter in question under Network Adapters, right-click on it, choose Properties, and open the Power Management tab and uncheck the Allow This Device to Wake the Computer.

Alternatively, it said you can keep that box checked, and check Only Allow a Magic Packet to Wake the Computer. I did that and later my SSH would consistently close down after a minute so I believe that was the culprit. So make sure that you don't have that setting on your network adapter changed from the default. Might have to restart your computer for any changes you make to take effect.

Improve this answer

You must log in to answer this question.

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