How to fix ssh timeout problems

If you use ssh a lot, you may have noticed that your ssh session times out and you’re logged out every once in a while. Annoying isn’t it?

Read from remote host Connection reset by peer
Connection to closed.

There’s a quick fix for that. Actually, there are 2 ways to fix it. You only need to do one of them so choose whichever one is easiest for you. You’ll need root access, so for most people it’s probably safer to do the client fix rather than the server fix.

  • On the server, login as root and edit /etc/ssh/sshd_config and add the line:

    ClientAliveInterval 60

    According to man sshd_config, this line,

    Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. This option applies to protocol version 2 only.

    Don’t forget to restart sshd on the server after you save the file.

  • The other way, and easier and safer way is for your desktop machine to send those keep alive messages. As root on your desktop (or client) machine, edit /etc/ssh/ssh_config and add the line:

    ServerAliveInterval 60

    That will send send a message to the server every 60 seconds, keeping the connection open. I prefer this way because I login to several machines every day, and I don’t have root access to all of them.

I knew I had blogged about ssh timeout problems before, but I hadn’t mentioned the client fix so it’s worth a revisit!



"How to fix ssh timeout problems", 5 out of 5 based on 23 ratings.

28 Replies to “How to fix ssh timeout problems”

  1. You are probably working around a NAT translation or dynamic firewall rule timeout problem by making sure traffic is sent more often than the timeout. You could fix the problem for all long-lived TCP connections by adjusting the timeout on the firewall or router to a more reasonable value.

    By sending traffic every 60 seconds over the connection you are likely to run into a new problem: if any physical link in the network between the client and the server is down for a couple of minutes, the connection is guaranteed to die. This is because TCP will abort the connection after it fails to receive a response to the packet with the SSH keep alive probe.

    I set the ClienAliveInterval to 3600 (one hour), which is low enough to work with the default timeouts in ip-filter (on NetBSD), iptables (on OpenWRT), Cisco PIX and Cisco routers with CBAC. Yet it is high enough to avoid most network blips in practise. This is certainly thanks to statistics and good luck in large part, as TCP will timeout much sooner than 1 hour once a packet is sent. Thus the trick is to send packets as infrequently as possible over idle connections.

  2. Thanks Kimmo. The problems started here when my home network went WiFi when a WRT54G was added. I’ve never been able to figure out what setting on the router to change to fix it.

    I don’t mind so much if my ssh dies because the network resets. I get a dynamic IP, and I use screen remotely. The timeout on ssh was such that I could test a web app for a few minutes and ssh was dead when I got back to my terminal.

  3. I use a combination of the excellent ExpanDrive (, keeping my SSH connection to my server alive at all times and treating it as just another local drive. I then use the terminal window within Path Finder (, a finder replacement, to do cmd-line stuff. Coda’s terminal window also works well with ExpanDrive, but the main point is that it makes your connection pretty much permanent.

  4. Hi Donncha, thank’s for the hint. By the way, it’s also a good idea to change the ssh standard port 22 to something else for security reason. You can do that in the same configuration file. The parameter is named Port. 😉

  5. Michael – not worth it IMO, a bot looking for a suspect version of ssh will find it no matter what port you put it on. Port knocking, now that’s more interesting, but hassle.

  6. Hm, you’re right, but if you running a firewall which deny port sniffering – than you should be lucky with a different port 😉 … in any case, it can’t be harmful and should improve security.

  7. When every I move to a new machine / upgrade existing machine, I forget to carry out this config change until I actually get a timeout! Thanks for the post that describes both server and client config options in the one place!

    Port kncking looks very interesting. Had no come across it before. Thanks again Mr. O’Caoimh.

  8. Donncha: actually, when possible, changing your ssh port to something non-standard DOES help protect you against some bot attacks.

    If you look in /var/log/secure, you’ll probably see a bunch of these:
    Jan 12 09:13:08 sxh1 sshd[22082]: pam_succeed_if(sshd:auth): error retrieving information about user admin
    Jan 12 09:13:11 sxh1 sshd[22085]: pam_succeed_if(sshd:auth): error retrieving information about user admin
    Jan 12 09:13:15 scx1 sshd[22141]: pam_succeed_if(sshd:auth): error retrieving information about user wrestling

    [root@sxh1 log]# cat secure | grep -c “error retrieving information about user”
    1250 (last 24 hours)

    These come from bots using username/password list and just trying to guess combos, a popular one is test/test, people create this account all the time to try things out. These bots don’t scan for the ports ssh runs on, they just blindly reach out to port 22. Changing it prevents these kinds of attacks.

    Now, if you’re the only user of a box, it’s pretty easy to maintain sanity, block 22 to only sources you trust etc, but as soon as you allow one other user, your level of trust goes down. In addition, some software will create users with default login credentials, sometimes without telling you, this will also help prevent this attack.

    The investment in time to change the port is very low, the potential risk is very high, I believe this IS in fact worth it.

    Thanks for the timeout tips!


  9. Thanks Donncha. It worked. Instead of trying it on the /etc/ssh_config, I feel it is better to try modify per user config file $HOME/.ssh/config, so you dont need root access. As Kimmo said, trying a longer ServerAliveInterval interval, say, 5 mins, is better 🙂

  10. @Mark Crowley: i think youd be much better served to address the ssh attack issue with something along the lines of fail2ban (on linux) which will blocks access to the machine via iptables after a configured number of failed login attempts, rather than add confusion over what port ssh is on. imagine if every website was on a different port how hard it would be to find you way around… i certainly wouldnt want to have to maintain a network of firewalls and servers around the world all on different ssh ports.

  11. @whojarr: You address your comment to the wrong person. Commenter name is after the comment. @dave is your man!
    I’m hope @dave appreciates your comment though! I like the look of fail2ban and am a long time fan of iptables.

  12. if you don’t have root access even at the local machine, you can use

    ssh -o “ServerAliveInterval 60” remotehost to connect

    or you can edit

    ~/.ssh/config and put

    Host *
    ServerAliveInterval 60

  13. man 5 ssh_config tells me:
    Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server.

    Seems to me then that if you are tail -f ing a log which is moving pretty quickly and simply watching it (not interacting), the server will still close the connection after you have been silent for too long…?

Leave a Reply