SSH Freeze

When I ssh from my office to my home (both ends running Slackware 14.2), I often get a screen freeze. I don't think this has anything to do with inactivity because it freezes most often while I am typing. The only way out is to kill the terminal and start again. The ssh rarely lasts more than 5 minutes, so it is really a big issue for me. I checked /var/messages, it shows that I logged in via publickey, but it doesn't show that it got disconnected. It could be my router that is acting weird, but I'd like to know how to narrow it down. Thanks.

Can't help with the why, but as a fix so that you don't lose what yur doing, try using 'screen' that way if u get disconected u can re attach to the session u was using

Originally Posted by asarangan When I ssh from my office to my home (both ends running Slackware 14.2), I often get a screen freeze. I don't think this has anything to do with inactivity because it freezes most often while I am typing. The only way out is to kill the terminal and start again. The ssh rarely lasts more than 5 minutes, so it is really a big issue for me. I checked /var/messages, it shows that I logged in via publickey, but it doesn't show that it got disconnected. It could be my router that is acting weird, but I'd like to know how to narrow it down. Thanks.

Check dis

So this article seems to point out that there are settings in ssh (client side) and sshd (server side) that prevent timeout by sending null packets periodically (which I think you know already).

But apparently once a certain amount of null packets are sent, it will still time out/freeze.

You can set higher null packet limits.

Worth a try.

Originally Posted by asarangan When I ssh from my office to my home (both ends running Slackware 14.2), I often get a screen freeze. I don't think this has anything to do with inactivity because it freezes most often while I am typing. The only way out is to kill the terminal and start again. The ssh rarely lasts more than 5 minutes, so it is really a big issue for me. I checked /var/messages, it shows that I logged in via publickey, but it doesn't show that it got disconnected. It could be my router that is acting weird, but I'd like to know how to narrow it down. Thanks.

After I posted this, I looked at /var/log/messages more carefully and saw that an unknown IP was attempting to continuously connect to server generating "Too many authentication failures". I am not sure if that was the cause of my freezes, but I didn't know how to stop this attack either, so I changed my ssh port to something other than 22. So far that seems to have fixed my freeze problem.

You should be running iptables and for pref fail2ban if u have an outward facing ssh connection

does the office use a NAT router? do you? these routers typically assume, by default, that usage is for HTTP(S) and set a short timeout for NAT table entries. whoever runs this router should look at the documentation thoroughly to see how to configure this. don't turn them off unless it lets you do it by port number since that will cause the router to run out of memory, eventually.

you can set up a VPN that uses UDP with pinging in both directions (every few seconds is probably good enough). that might have better luck than TCP.

Try to use "ssh -C" with compression. Usually this helps me with bad network.

Originally Posted by permaroot Check dis

That link is broken. It navigates to

www.https.com

ironically via http protocoll. This is the content of your URL field:

http://https://unix.stackexchange.com/questions/200239/how-can-i-keep-my-ssh-sessions-from-freezing#200256

Even if you run on non-standard ports I recommend FAIL2BAN.

I once set up a honeypot running FAILTOBAN and services on normal ports on my network. I forwarded the block addresses to my gateway, thus adding protection to my entire network.
I linked in whois to get a report on the source subnets, compiled the result by country, and created a web page with a running graph of what parts of what countries were trying how hard to break in today. Overkill, but the it sure made for some fun reading.

I was so impressed with the behavior of failtoban that I installed it on the most at-risk data servers at work. We never had a successful breach.

Originally Posted by wpeckham Even if you run on non-standard ports I recommend FAIL2BAN. I once set up a honeypot running FAILTOBAN and services on normal ports on my network. I forwarded the block addresses to my gateway, thus adding protection to my entire network. I linked in whois to get a report on the source subnets, compiled the result by country, and created a web page with a running graph of what parts of what countries were trying how hard to break in today. Overkill, but the it sure made for some fun reading. I was so impressed with the behavior of failtoban that I installed it on the most at-risk data servers at work. We never had a successful breach.

Thank you for all the responses. I did confirm that the frequent freezes were due to attacks on my server from repeated attempts to login. Once I switched ports, everything was fine. I need to look into how to secure using fail2ban.

Originally Posted by asarangan Thank you for all the responses. I did confirm that the frequent freezes were due to attacks on my server from repeated attempts to login. Once I switched ports, everything was fine. I need to look into how to secure using fail2ban.

In addition to fail2ban, there is also sshguard. Look at both and then decide which has the features you are looking for.