Fixing Bad SSH Connections?

Pilchie asks: "I often use SSH to access my computer at home, when I am either at work or at school. My problem is that I can't seem to make the connection persistent. I connect, and usually within about 30 minutes, all my Xterms are frozen, and I have to kill my SSH client and start again, which is annoying when I am coding something. My question is twofold. First, how to determine if it is something to do with SSH Client or Server, or whether it is my ISP's network which sucks? Second, Is there anything I can do about it?

"Here's a description of my system:

• Home machine: P166, 128MB RAM, running Debian Potato.
• SSH Server 1.2.27
• Remote Machine: PIII 450, 256MB RAM, running NT 4.0.
• SSH Client the windows one by Cedomir Igaly Rev 2.112, with Exceed as XServer
• Net connection: Cable Modem from Rogers@Home (Brampton Canada, near Toronto) (Note: It is one of the new Terayonones which doesn't have an IP address, uses DHCP and SNMP)

Lastly, two pieces of information that I think might be key. First, if I traceroute to my home machine just after the connection dies, I get to the gateway machine for my ISP subnet, but not to my machine. Second, when I used to do this from school a few months ago, on a Solaris 2.7 box, I would often have problems connecting, with the same thing happening with traceroute. However, once I got connected it usually worked fine.

Any ideas, anyone?"

Duh

[crovax]

Why I didn't think of it first I don't know, but did you try going into SSH debug mode on the host machine?
-----
If my facts are wrong then tell me. I don't mind.

A possible reason and solution

[seth]

I found that with ipmasq, my ssh connection would close unless I was in a program such as mutt or screen. I did further research and found this link [home.net] which mentions that ipmasq connections will die after a timeout period. The solution (which I haven't actually tested, 'cause I'm almost always in mutt or screen) is to set a longer timeout.

Solution to same problem.

[nikhil]

I have expierence the exact same problem. My ssh sessions would time out if they were idle.

My solution was just doing /bin/echo -e "300\c" > /proc/sys/net/ipv4/tcp_keepalive_time

That would increase the keepalive time, thus stop the disconnects. Ever since I've done that I've never had a problem again.

Depending on your version of bash you might not be able to do /bin/echo -e "300\c"

You want 300 without a line break so you might have to do
/bin/echo "300\c"

This should help you and all others who have this problem.

unset autologout / DHCP

[Plagued by Penguins]

If you're using tcsh then make sure autologout is unset. What might be happening is that the tcsh session from which you're firing up your remote xterms is logging out, and thus leaving ssh nowhere to connect to. So it hangs. The 300s thing sounds a lot like this. All my rxvt sessions stay up for days on end over ssh and have never died unless my PPPoE IP dynamically changes.

Oh, I guess that's another thing - how often does DHCP/pump(?) change your IP address? If that changes regularly (which it's allowed to do) then ssh would hang...

IPchains solution ?

[BigJim.fr]

echo -n "Adjust timer to prevent ssh and telnet session timeout" ipchains -M -S 144000 60 3600 echo "done"

Re: Smells like Rogers tech support to me =)

[billcopc]

Funny how the guy mentioned he's using a cable modem. Last I heard, cable modems hooked up to the cable lines.

In this light, I think you'd make a great Sympatico/Rogers call center clerk.. a supervisor even.

probably not a ssh prob

[Jose]

if I traceroute to my home machine just after the connection dies, I get to the gateway machine for my ISP subnet, but not to my machine

sounds like a crappy rogers cable connection. When you are at home do you ever notice short outages of net access? From what I've seen it is quite common for cable modems to go offline for 30 seconds or more every hour, which could explain why your ssh's are locking up. I'm sure there is an option to lengthen the timeout time in ssh, read the man page.

hints

[vasquez1]

I'm a bit late, but I was fighting the same problem. A few hints:

• you almost certainly are using ipmasq'ing. Set the timeout for tcp connections with ipchains higher than the keep-alive time of sockets in the kernel. Standard for ipmasq tcp timeout is 15mins or so, but the keepalive time is 2 hours! (see two posts above on how to do this.
• if your target machine runs a 2.0.x kernel: I still have problems with that one. I don't know why. Upgrading to 2.2.x is probably the best solution.

Do you pass a statefull firewall . ?

[DeeDee]

SSH has a protocol that doesn not poll to keep it's session active : You can completely pull out your routes , wait for 5 minutes and you can continue ..
This might sound OK , but it also has a downfall:
as long as you are not typing , there is no traffic generated from your side. If you would pass for example a Checkpoint Firewall , the tcp timeout in the root checkpoint config will close the connection after the defined tcp timeout , usually 30 minutes. Even running a tunnel with X for example will not help as the tunnel traffic does not get counted ( I do not know why )
The work around we have created here is to start a script in the background that shows the date every 25 minutes, this the looks like you have a person typing in 'date' and keeps the tcp session up and running ..

Hope this helps

D.

The easy way..

[Rob Kaper]

When doing nothing, simply run a program that updates the screen. Nothing to configure so you can even use this for machines you do not have root for.

I usually use joe, it updates the screen every minute because it has a clock in the title. Besides, having an editor open never hurts, right?

Since I do most of my work in screen, ^Ac joe has become a rather standard procedure for me.