1 Reply Latest reply on Apr 24, 2018 5:26 PM by rp0428

    SSH & DB Connections - Keeping them alive

    Phil Broughton

      I have an environment that permits me to use sqldeveloper on my laptop, to connect to a jump server over ssh, that connects to the database targets over SQLNET.

       

      This is great, sqldeveloper allows me to use SSH port forwarding.

       

      However, what I need the SSH tunnel to do is "stay alive". The networks to the jump service clearly have a strict/short TTL and drop the connection if I go away and get a cup of coffee.

       

      What would be really cool is if SQL Developer was somehow able to send a background sql transaction (select user from dual;) every 'x' seconds or preferably, allow the SSH tunnel client to send null packets/TCP_Keepalives to keep the connection going.

       

      Does anyone have a workaround?

       

      I know there is something that could be adopted by creating a bespoke version of sqldeveloper with jdeveloper and https://github.com/scristalli/SQL-Developer-4-keepalive however, I would rather the product owners provide the solution. Call me old fashioned

        • 1. Re: SSH & DB Connections - Keeping them alive

          however, I would rather the product owners provide the solution. Call me old fashioned

          Unfortunately I don't think 'old fashioned' is the term experienced security folk would use.

           

          Those keep-alive mechanisms essentially subvert security and make it harder to properly protect systems from unauthorized use.

           

          I certainly don't agree that a vendor should support such methods and take that control out of the hands of orgs that want to protect their systems..

           

          I can't speak for the Sql Dev team but I would be surprised if Jeff Smith's opinion has changed from what he posted back in 2011.

          https://www.thatjeffsmith.com/archive/2011/10/day-1-give-me-a-keep-alive-button/

          I completely understand why you want this feature and know where the pain is coming from, I just don’t agree with this approach. I’m afraid it would be abused and hide infrastructure flaws in your network.

          Imagine a dba running a top Sql report and noticing a few hundred Sql dev users running all this nonsense Sql, just to keep their sessions established.

          I get asked all the time how to build logon triggers to keep users off a system – I think his might serve to add fuel to that fire.