SSH features

This feature looks really useful, though for it to be really attractive to me it would need to support more authentication methods so I don't have to type in my password all the time. Private key authentication would be good. GSSAPI would be even better. Also I found the UI kind of confusing. I still apparently have to type in the database server as 'localhost' which I think is counter intuitive. What I'd like to see is the ability to simply specify that I'm using an SSH tunnel by checking the box and have it simply work (i.e. it assumes by default that I want to SSH from my current machine to the DB host I specify in the 'Database server' field, and then have the SSH host and port fields be optional if for the occasions I need to bounce off an alternative DMZ server for access. I don't really think I should ever have to put 'localhost' into the Database server field unless I'm actually running a DB instance on the same machine as DBVis.

Hi Brad, Thanks for the feedback. We will try to get support for private key authentication added before the final release. Other methods may be added later if there is demand for them and bindings to Java that we can use. Regarding having to enter "localhost" as the Database Server, the only case we know of where this is needed is when the database is configured to only accept connections from "localhost". Like I mentioned in another reply, the fields are used like this in a corresponding ssh command: ssh -p -L:: @ I'm no expert on SSH, but it appears as if the part is used as the bind address for the socket that sshd on the sets up to the . If the database only accepts connections from "localhost" (i.e. 127.0.0.1), you must set Database Server to "localhost". But if it accepts connections from its own network IP (i.e. the IP address that corresponds to the name you set in Database Server), it works like you imagined. We appreciate all feedback on this, since there most likely a lot of different configurations out there. If there's a more intuitive way to do this, please let us know. Best Regards, Hans

I also have to agree about the private key, and GSSAPI. However, they are using jsch, so it is supported out of the box, however they will have to tweak the interface a little. From my experience, it didn't assume that I was starting a ssh tunnel, I had to check the box and then I was given more options to fill out about the ssh connection. The interface was easy and understandable, however, I was looking for a way to specifically set up forwards and local ports, but didn't know it did it for me (Which is great!). So I guess a help overlay would have assisted me in this case.

>But if it accepts connections from its own network IP (i.e. the IP address that corresponds to the name you set in Database Server), it works like you imagined.:localhost:5432 db.foo.com where local port is auto-generated. If I were to specify an SSH server of 'dmz.foo.com' I would expected the equivalent command to become ssh -L:db.foo.com:5432 dmz.foo.com. This should cover all the use cases but still always allow you to leave the UI DB hostname set to the actual hostname of the machine where the DB is running. And yes, if you're using jsch as your connection layer, you should be able to support GSSAPI with little difficulty, with most of the work simply revolving around updating the UI to allow for alternate / multiple authentication methods. Edited by: Brad Davis on May 4, 2011 2:44 AM

Hi Levi, Regarding making it easier to understand how to fill out the SSH category fields, would it help if we could show the corresponding ssh command based on the current settings somewhere, e.g. after the checkbox in the Use SSH Tunnel when it is enabled? Or do you have any other ideas? Best Regards, Hans

Hi Brad, > I'm not the admin for the datbase to which I'm connecting, nor its host machine, but I do get an error when I specify the full hostname as the database server instead of 'localhost', which seems indicative of some sort of network restriction. What I'm suggesting however is that the UI be more simple for what I believe to be the most common use case. Ideally most of my current tunnels should be replaceable by a simple checkbox in DBVis > > Given > DB Host: db.foo.com > DB Port: 5432 > SSH Enabled: True > > I would expect DBVis to construct a tunnel equivalent to > > ssh -L:localhost:5432 db.foo.com > > where local port is auto-generated. If I were to specify an SSH server of 'dmz.foo.com' I would expected the equivalent command to become > > ssh -L:db.foo.com:5432 dmz.foo.com. > > This should cover all the use cases but still always allow you to leave the UI DB hostname set to the actual hostname of the machine where the DB is running. Thanks for the suggestion. I understand your point and I'm all for doing this as simple as possible. If you are correct in that a very common case is that databases accessed via SSH only accept connections from "localhost", what you suggest makes sense. The problem is that I am not sure that this is more common than the case where the database accepts connections from its network IP address. In our testing, we have encountered the scenario you describe with a MySQL database. Is that the database type you connect to as well. Could it be that this is the default configuration for MySQL, but not for other databases? When testing this with Oracle and other database (in our own, limited test environment which may not be typical), using the network IP address worked fine. I would really appreciate more feedback from you guys dealing with this "in the real world" so we can come up with defaults that make sense for the most common configurations. Best Regards, Hans

I'm working with a Postgres DB, and it looks like the default pg_hba.conf file specifies the ipv4 and ipv6 loopback addresses as allowed and nothing else.

I'm using Postgres hosted on Amazon EC2 environment. The only port open to the outside world is SSH (on a non-standard port), and my authentication is based on an RSA private/public key pair, configured without a password. Currently, I'm port-forewarding using Cygwin ssh client. So far, haven't been able to figure out a way to configure a direct connection to the DB.

Hi Jerzy, Thanks for the feedback. Please give it a new try when we have added support for key authentication. Best Regards, Hans

Hi Brad, Thanks for the clarification. Best Regards, Hans

Hi there, i've been tested the SSH feature and it work all fine for me. But it should be possible to save the authentification infos within the properties like for the database connection itsself. Vote for RSA, GSSAPI and other fingerprint support cheers Nesmoon Edited by: nesmoon on 10.05.2011 13:22 Edited by: nesmoon on 10.05.2011 13:23 Edited by: nesmoon on 10.05.2011 13:23

Hi nesmoon, Thanks for your feedback. > i've been tested the SSH feature and it work all fine for me. But it should be possible to save the authentification infos within the properties like for the database connection itsself. You can enable "Save Password" in Tool Properties, SSH Settings. > Vote for RSA, GSSAPI and other fingerprint support Support for private/public key authentication has been implemented and will be included in the next EA, to be released shortly. Best Regards, Hans

ah great, didn't mentioned that in Tools->properties but searched for that for a already established database connection. If you choose the slider "properties" there is no equivalent entry for that. Edited by: nesmoon on 11.05.2011 17:35