Strong recommendation: Use session timeout tuning only as the very last and ultimate resort.
Because today it will be 3hrs, and next week, the DB admins will ask for 10hrs for their long-running daily ssh-based remote-command-execution job. Which will run fine for half a month, then the amount of data processed by the remote job increases by 40% (because it might be payroll processing day on the 25th), and the job fails because its idling TCP connection gets killed after 10hrs. They'll come asking for 18hrs. You don't want to know what they'll be asking for for the end-of-year processing jobs.
There's keepalives for that:
TCP Keepalives need two things:
a) The TCP keepalive time on (one of the two TCP speaking) end systems needs to be cut short from default of 2hrs down to something like 10 or 15min. That's usually a global parameter for the entire Operating system. Windows has KeepAliveTime for that, (as explained in https://blogs.technet.microsoft.com/nettracer/2010/06/03/things-that-you-may-want-to-know-about-tcp-keepalives/ and almost anywhere you search for "Windows TCP KeepAliveTime")
b) the application itself MUST set the SO_KEEPALIVE socket option when initiating (or responding to) a TCP connection. Many applications do this by default, some are configurable. Only if SO_KEEPALIVE is enabled for the given TCP connection, the reduced TCP keepalive timers come into play.
Yes, Developpers and Systems Admins will complain at first and refuse to to their part of the work - but in the end, it's worth the effort, and once they understand that they can actually control the longevity of their idling connections themselves, they're happy.
On the other hand, it's one of the big misteries of the IT world why every Operating System defaults to 2hrs, while the firewall industry seems to default to 3600s or even 1800s.