Disabling ssh timeout (PuTTY and Tera Term Pro SSH)

[LVLouisCyphre]

It's been awhile since I assembled a maintained a FreeBSD data center (fall 2012) back in the FreeBSD 8.x days when I was forced into a disability retirement from my IT career. Now I'm at FreeBSD 13.1 and I'm scratching my head going through man pages and the handbook and can't find the simple answer on how to disable sshd from timing out. When I'm logged into my laptop at home in the same LAN behind the firewall, I want to be able to keep an active ssh console going at all times. The head of the server (keyboard, monitor and pointing device) do not disconnect, but my ssh sessions within the same secure LAN do. What do I need to change in what files to keep an indefinite session alive with PuTTY or Tera Term Pro SSH. I would like to have my laptop stay logged in running a top -s1 which is what I do as a habit to monitor a server. It gives me a snap shot of the server's health. I'm also open to someone who has a better recommendation for ssh clients. I wouldn't be surprised if PuTTY and Tera Term Pro SSH are outdated and no longer recommended for net and sys admin.

I understand FreeBSD has gotten much more security intense since I last majorly deployed it almost a decade ago. Not surprising since hackers get more creative all the time and network security needs to evolve. I feel like Scotty from the ST:TNG episode Relics. Someone help an old man out. I know I'm missing something, but what? I also know I have a decade of catching up to do so please bear with this old man.

 

[zirias@]

All I can tell is that sshd does not timeout sessions. So it's either a network problem or some strange behavior of the client.

 

[VladiBG]

The server side "sshd" default settings of "ClientAliveInterval" is 0 which means the server will not disconnect the client even if no data is send by client. In "NAT" network when there's no data transferred there's a router timeout which close the TCP session and cause the disconnect in such cases you can use a client side keep alive packets using "ServerAliveInterval" and "TCPKeepAlive" which will force the TCP session to stay open but in your case when you are in same network segment and there's no NAT this will not apply for you.

Anyway you can try set the "TCPKeepAlive" on the client it will not harm.
If you are using putty client on window the settings is here:

 

[diizzy]

While it's not that common you might see this issue if you have configured very agressive timeouts in a firewall

 

[Phishfry]

I have to agree with all here. SSH Doesn't timeout.
When I looked at pftop after dizzy mentioned firewall I see my ssh session has 24hr lifespan.
Its worth looking on your firewall stats.

Is this affecting all SSH users or only SSH root logins?

 

[Professor_Fate]

Interesting this is happening to you in the same LAN. Back when our company was overreacting to COVID and forcing people to work from home, I discovered I would get SSH timeouts (but only when connected to our FortiGate VPN. Connecting through our OpenVPN node did not have this problem). Setting ServerAliveInterval 290 fixed it for me. Don't know about PuTTY, I use the SSH client built into Windows 10.

 

[hardworkingnewbie]

SSHD doesn't timeout unless configured that way.

Does your configuration contain values for these variables which are not 0?

ClientAliveInterval 1200
ClientAliveCountMax 3

Then it's easy: timeout value in seconds is the product of above two.

For Openssh versions < 8.2 that automatically closed your connection. Since >= 8.2 it will only disable the keepalive functionality (https://bugzilla.mindrot.org/show_bug.cgi?id=2627).

Another problem source could be the ISP. Some ISPs have a network connection disconnect in place after a certain amount of time.

 

[LVLouisCyphre]

Everything is at the FreeBSD 13.1 installation defaults. There's no firewall enabled on the server at this time the laptop and server are in the same subnet/VLAN. I'll try the suggestions made thus far and see if there's some progress. It's not a network issue as I've run continuous pings from the Windows 10 client with no loss of packets. Tera Term Pro SSH hasn't changed much, if at all, since I last regularly used it. I'll try changing the null packets and enabling TCP keep alives in PuTTY. If that works then I'll see what I need to do in Tera Term Pro SSH.

The thing that bothers me is that if I'm running top -s1, shouldn't the connection be kept alive as top is updating the display every second. Scratching a new bald spot in my already receding hairline here.

 

[LVLouisCyphre]

I think I caught it. Right now I have a Vonets VAP-11G as a wifi bridge until I get the final cabling completed while doing QA testing and burn in of my server. Does anyone have any recommendations on a good ethernet to wifi bridge so I can exclude this device; preferably something that does 802.11ac? I suspect this Vonets device isn't designed for enterprise level wifi bridging. It works perfectly with my old HP LJ2100 printer with an internal JetDirect card and Slingbox Pro (yea, I'm a technogeek and need my techy comforts, who isn't here?) probably because there's only one device and MAC address going through the wifi bridge from the wired side. I suspect the Vonets bridge goes stupid when its MAC address table is flooded with devices on the wired side.

 

[Incnis Mrsi]

SSHD doesn't timeout unless configured that way.

Perhaps it doesn’t per own volition, but the operating system (the networking stack of any OS, not BSD specifically) quashes TCP sockets which don’t show any motion within specified duration of time. FreeBSD controls it with

net.inet.tcp.keepidle
net.inet.tcp.keepintvl

(in milliseconds) of sysctl(8) and sysctl.conf(5). Linux analogs are net.ipv4.tcp_keepalive_time and net.ipv4.tcp_keepalive_intvl (in seconds).
If one endpoint is going offline for long, then it’s helpful to permanently push its MAC (with arp(8)) to the ARP table. Either at another point or on the router, depending on the route. Any attempted traffic toward a host dropped from ARP results in reset.