2

My SSH sessions die at what seem like random times - response will stop, and then a few seconds later PuTTY will pop up a message with, "Server unexpectedly closed network connection." It seems to most often happen when idle, but not always - it might even die when I'm typing in vim or something (very frustrating!). But it's pretty frequent - if I'm very lucky it might survive for a few hours, but if I'm unlucky it might die within seconds or minutes of a login.

  • Server: VPS with CentOS 5.6, WebMin 1.62, OpenSSH 4.3
  • Client:
    1. FTTH (or probably more accurately, to the building: 104 condos)
    2. router #1 running NAT and security
    3. router #2 running just as wireless access point
    4. Windows 7 laptop (but I had the same problem with an XP desktop)
    5. PuTTY 0.62

Most of the time I don't even use the wifi, but just connect TCP-IP (with a hub) to router #1 - but the problem remains. I assume the fundamental cause is hiccups in my ISP's connectivity (or something in the building), but I probably can't solve that, so the reason I'm asking this on ServerFault is because I'm just trying to configure SSH (or PuTTY or whatever it takes) so that it doesn't terminate the session so easily.

I have tried various things that other people have found useful:

  • Setting PuTTY's Connection->"Seconds between keepalives" to various non-zero values (I don't know if that setting is like TCPKeepAlive or more like ServerAliveInterval, but it's the only setting available in PuTTY)

  • Trying to make the server do the work, by turning PuTTY's keepalive off (0) and then on the server, including this in sshd_config:

    TCPKeepAlive no
ClientAliveInterval 60
ClientAliveCountMax 3000

  • Changing to a static IP for my PC (that was the solution for this question on SuperUser.com)

But it still dies in all variations - it's difficult to tell if one set of settings is slightly better than another, but each has failed even today in less than an hour. And this problem is quite consistent over the long term - I have put up with it for the couple years I have been managing this server (I'm mostly a programmer, so I don't spend a ton of time in SSH, but when I do need it, it's frustrating to keep losing my session). Any thoughts?

Improve this question
4
  • Do you have a static external IP address or is it dynamic ?
    – user9517
    Aug 16, 2013 at 7:52
  • Static - it's being used as a web and mail server, etc., and I do connect using the literal IP.
    – OsakaWebbie
    Aug 16, 2013 at 8:05
  • 1
    Answers should be posted as answers, not as edits to the question.
    – Michael Hampton
    Sep 12, 2016 at 5:31
  • I didn't think such an update would qualify as an "answer" to my original question (since the question was about the server and SSH but the solution was local), but at your suggestion, I moved it. I'm still learning the StackExchange culture, if you know what I mean.
    – OsakaWebbie
    Sep 12, 2016 at 23:57

2 Answers 2

Reset to default
4

When I have this problem, it's either due to an unstable internet connection (which in my experience is increasingly rare), or due to configuration on the server. My connections usually stay open for > 8 hours.

I'd suggest setting TCPKeepAlive to yes, since this will enforce the sshd server to be the peer that keeps the connection alive. I've never had to change anything in Putty itself.

The relevant parts of my sshd_config:

TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 3

Let me know if this helps.

Improve this answer
6
  • From what I read, TCPKeepAlive and the ClientAlive* settings were two separate methods that the server could use to keep the connection alive, and that they shouldn't be used together (and that TCPKeepAlive was unsecured, so was the less desirable of the two). Was I given bad info? Anyway, I've changed the settings to what you suggested, and I'll let you know what happens.
    – OsakaWebbie
    Aug 16, 2013 at 9:38
  • It died with these settings also.
    – OsakaWebbie
    Aug 16, 2013 at 10:17
  • Disabling TCPKeepAlive is not recommended, according to the sshd_config man page, but you're right: it shouldn't have any real impact on what we're trying to accomplish here. Have you tried lowering the interval for the ClientAlive requests?
    – Jaap Haagmans
    Aug 16, 2013 at 13:12
  • I would think that would make it worse, not better (more likely to catch the connection in hiccup mode), but I tried lowering it to 10 seconds. No dramatic difference - my next session lasted about 15 minutes.
    – OsakaWebbie
    Aug 16, 2013 at 14:45
  • The Client Alive requests are there to keep the connection open (by sending requests to the client). The TCPKeepAlive directive is there to close inactive connections. So I agree that seems counter-intuitive to set it to on, but it works for me (and I have the same problem as you on default settings) and guarantees I have no ghost sessions. I know this is going to sound lame: you did restart sshd after editing these settings, right? In your case, I agree that the best bet would be to disable TCPKeepAlive (your connection appears instable), but I'm out of clues since that doesn't work either.
    – Jaap Haagmans
    Aug 16, 2013 at 15:11
1

The problem sorta resolved itself - I'm writing this answer to share what happened, for those who might read it later...

During the same period I had problems with my LAN-based printer throwing a "Network board error" and having to be restarted on an almost daily basis - I didn't connect the two problems because they seemed to occur at different frequencies, and because the printer driver was blaming the printer while SSH was blaming the server. When the printer errors seemed to be increasing, I decided that the machine was dying and replaced it (a several-hundred-dollar business-level color laser). But the new one had the same problem! That's when I realized that the cause was outside the printer, and started thinking it and the SSH problems (and Skype connection interruptions) might have the same cause. I tried replacing my router, to no avail. I researched some other things, but came to no conclusions. Then, after suffering with these things for a couple years, my husband replaced his PC, and all the problems suddenly went away! Apparently his PC was somehow interfering with everything on the local network, but only certain processes would show obvious symptoms, and only intermittently. My point: if someone finds this thread who has a similar problem, check the devices on your LAN, even ones that seem to work fine.

Improve this answer
2
  • If you still have the old machine, you might boot it up on a diskless image, scan for viruses / malware. Some malware is coded .. poorly and can flood a small network by design or by mistake. It could also be that his pc was trying to use the gateway address for it's IP. Or perhaps IP conflict with just the printer. So many possibilities.
    – Aaron
    Sep 13, 2016 at 2:06
  • No, it's long gone. But I'm pretty sure it had no malware, as my husband tends to be paranoid and do deep scans whenever it does something unexplained. And I know it wasn't an address conflict with the gateway or any other device. Our best theory was regarding the "master browser" in windows networking - although my PC was normally the master browser, sometimes his would also try to take that role. We never figured out how to get it to behave, and we were never sure whether that was the cause of the LAN hiccups.
    – OsakaWebbie
    Sep 13, 2016 at 13:45

You must log in to answer this question.

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