You want to connect to the database, but:
- you can’t get to the server directly, or
- you can’t talk to the listener port
If ONLY there were a way you could smuggle your database connection through another network connection that could do those things.
Well there is, and it’s called an SSH tunnel.
SSH talks on port 22 – which is more often than not open on your locked down servers.
So if you can get a SSH connection going, you could send SQL*Net traffic over that connection…and on the other end of the tunnel, you could establish connections to the database.
That’s not the most eloquent description of the concept, but we have Wikipedia to help with that. And I’m guessing that everyone reading this will already be intimately aware of SSH tunnels.
Instead of having to do it outside of SQL Developer, now you can define/create those tunnels with the tool itself.
So, after you…
Upgrade to Version 4.0.3…
…you can now do this 🙂
And provide your authentication details
Now, my ssh connection is a bit weird. I’ve simply created a port forwarding scheme in my VM – traffic on port 22 on the host is forwarded to port 22 on the Linux VM. And then from there, the server will open a connection to the database.
If you’re using an IP address or server name in your regular Oracle connection properties – that info HAS to make sense to the server that you have SSH’d into.
Today and Tomorrow
Today, the tunnel is defined at the connection level. Now, you will probably need to create tunnels for more than just one connection, and many of them might be shared.
So, in an upcoming release, we see having the ability in the preferences to define your tunnels, and reuse them as you define each connection.
Now the ‘Tomorrrow’ Bit
We updated the ssh tunneling interface for version 4.1. You can define 1 tunnel and use it for multiple connections. The tunnels are defined and managed in the View > SSSH panel.
Defining the SSH tunnel AND the port forward:
Now use the tunnel in your connection properties:
Oracle ACE Danny Bryant has a nice 4.0 vs 4.1 SSH Tunneling overview here.
24 Comments
It is very useful feature, but I would need to set an ssh option without which I cannot establish the connection (KexAlgorithms=diffie-hellman-group14-sha1). I work with Fedora and tried to modify the ssh_config file, but it works only in console.
Can it be setup for the SQLDeveloper’s connection?
Thank you,
Enrico
We’re working on a way to let folks set custom ssh connection properties, but for now you’ll have to use putty/whatever to open your own tunnel.
Like!
Andrew, thanks for reminding me to update this article to show how the tunnels are defined in version 4.1 🙂
Hi Jeff, is it possible only with key? I tried to connect with an SSH-Host with username and hoped to get question about my password. But I got only this error: An error occurred while opening the host connection:
com.jcraft.jsch.JSchException: Auth fail
🙁
Thanks,
Eugen
key’s aren’t required in general…you’ll have to have a key to access our DBaaS instances though
What is the best way to generate a local keyfile to use with sqldeveloper on Windows 7… tools like putty automate the validation and storing of keys.
you’ll have to generate the key on your own, we’re only sending said key for the ssh connection request
Hi, Jeff, I’m trying out the 4.1EA2 (4.1.0.18.37), but can’t figure out, where to find the “SSH tab”.
I can’t get it displayed while setting any value from the “Connection type” dropdown.
PS: I use ssh tunnels extensively, so I find this a quite nice feature.
View > SSH – we changed this feature for 4.1 just this week. Oracle ACE Danny Bryant has a nice post on his blog about this.
Thanks, I found it a while later. And another while later I remembered, I also use sqlplus, so I still have to use the tunnels/tnsnames combo.
Nice feature, however.
If I didn’t need sqlplus so often, I would definitely switched to it.
Our new sqlplus will have the tunnel feature as well. Stay tuned 🙂
Hi,
I’m trying to get this nice feature to work on Version 4.1.0.19.
When I test the freshly created connection I get a stack trace:
com.jcraft.jsch.JSchException: The cipher ‘aes256-cbc’ is required, but it is not available.
at com.jcraft.jsch.KeyPair.loadPPK(KeyPair.java:1035)
at com.jcraft.jsch.KeyPair.load(KeyPair.java:591)
….
Any ideas?
I’m using 4.0.3.16.84 and the SSH tunnel doesn’t appear to work. I can see it’s able to log me into the ssh server with my ssh key. A test of the oracle connection fails. When I do a tcpdump, I see the problem. The connection made out to the Oracle DB tries to connect as the username set in the SSH tab, not the Connection’s username which is the username for the Oracle DB. This sounds like a bug in the sqldeveloper ssh tunnel code.
That would be a bug, can you report it to My Oracle Support? Or at least post it to the OTN Community/Forums.
The DBAs have the support with Oracle, not I, so I only posted in the forums.
https://community.oracle.com/message/12802603
Thanks, but if this is business critical, have the DBAs create the SR for you. Or have them add you to the My Oracle Support contract list – it’s very easy to do.
Hi – I can’t get the SSH tunneling to work, the only examples I can find are where the SSH “jumphost” is the same as the DB host. I have a situation where:
Mac -> jumphost:22 -> dbhost:1525
SQL Developer connects to the jumphost just fine, but it cannot connect to the DB host.
This is the tunnel I use to get around SQL Developer:
ssh -L 1525:dbhost:1525 myuser@jumphost
Thanks,
David
Hi David,
have you found a solution for that problem?
I am facing the same scenario.
Regards
Rudy
Nice feature, which allows to use remote connection without extra tools and makes it quite clear 🙂
Good job and thanks!!!
This is really great. Was looking for that just this Monday 🙂
Thanks ! Very nice feature indeed 🙂
This is a great feature – hopefully you also allow us to save the password for the tunnel tomorrow 🙂
Tomorrow, yes…many improvements here to come with our 4.1 release. So stay tuned.