Re: SSH Tunneling implementation

On Fri, Jul 13, 2012 at 10:24 AM, Ashesh Vashi <
ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:

> On Fri, Jul 13, 2012 at 2:45 PM, Magnus Hagander <magnus(at)hagander(dot)net>wrote:
>
>> On Fri, Jul 13, 2012 at 10:32 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> > On Fri, Jul 13, 2012 at 7:57 AM, Akshay Joshi
>> > <akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>> >>
>> >>
>> >> On Thu, Jul 12, 2012 at 5:44 PM, Magnus Hagander <magnus(at)hagander(dot)net>
>> >> wrote:
>> >>>
>> >>> On Thu, Jul 12, 2012 at 2:06 PM, Akshay Joshi
>> >>> <akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>> >>> >
>> >>> >
>> >>> > On Thu, Jul 12, 2012 at 5:21 PM, Dave Page <dpage(at)pgadmin(dot)org>
>> wrote:
>> >>> >>
>> >>> >> On Thu, Jul 12, 2012 at 12:04 PM, Akshay Joshi
>> >>> >> <akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>> >>> >> > Hi All
>> >>> >> >
>> >>> >> > I have tried a lot to figure out libssh2 is compiled with which
>> >>> >> > crypto
>> >>> >> > library, but unable to find it. Can someone guide/help me or do
>> we
>> >>> >> > continue
>> >>> >> > with the public key option on UI?
>> >>> >>
>> >>> >> The libssh2 guys couldn't tell you how?
>> >>> >
>> >>> >
>> >>> > I'll post this on mailing list, but I have found one solution
>> to the
>> >>> > problem is checking the function "libssh2_md5" using AC_CHECK_LIB as
>> >>> > below
>> >>> > AC_CHECK_LIB(ssh2, libssh2_md5, [IS_LIBSSH2_OPENSSL_CRYPTO=yes],
>> >>> > [IS_LIBSSH2_OPENSSL_CRYPTO=no])
>> >>> >
>> >>> > I have analyze libssh2 source code and found "libssh2_md5" is
>> >>> > implemented
>> >>> > only for openssl version not for the gcrypt. I have tested it with
>> both
>> >>> > the version of libssh2.so.
>> >>> >
>> >>> > Thoughts? Comments?
>> >>>
>> >>> Is there a way to test the actual function that we want to call
>> >>> instead? Will it fail right away, or does it actually require there to
>> >>> be a server somewhere that we can connect to? (If it requires a server
>> >>> we can't use that one in configure, but if it will fail right away,
>> >>> that seems like a better way to test it.
>> >>
>> >>
>> >> To check the actual function we requires a valid server. Yesterday
>> I have
>> >> posted the problem to the libssh2 mailing list, but still didn't get
>> >> response.Meanwhile
>> >> I have fixed the review comments given by Dave. Attached is the
>> complete
>> >> patch with
>> >> AC_CHECK_LIB(ssh2, libssh2_md5 [IS_LIBSSH2_OPENSSL_CRYPTO=yes],
>> >> [IS_LIBSSH2_OPENSSL_CRYPTO=no]) and it works with both version of
>> >> libssh2.
>> >>
>> >> Can we include libssh2 source code with pgAdmin3 to solve the
>> problem?
>> >> Thoughts??Comments?
>> >
>> > I discussed that with Ashesh on Skype yesterday - I thought he was
>> > going to post to the list. Magnus suggested that option, and I'm
>> > beginning to think it's the way forward. The licence is compatible
>> > from what I can see, so that shouldn't be a problem. Then, we'd just
>> > modify the configure script to add a dependency on OpenSSL instead.
>>
>> Agreed. It seems libssh2 is just a little bit "too new" (IIRC it's
>> been around for longer, but caught some "revival" not too long ago) -
>> meaning that enterprise platforms like ubuntu LTS and RHEL are stuck
>> on versions that are too old.
>>
>> So I think including it would be a good idea - at least for a couple
>> of yeas until reality might change underneath us and make that
>> unnecessary.
>>
>> One thing we should definitely have is a policy (and maybe scripts?)
>> to make sure we keep it *updated*. It will require things like a
>> security release of pgadmin whenever there is one of libssh2, and we
>> need a good way to keep up with the proper minor version..
>>
>>
>> > If we do that though, we'd need to make it work if OpenSSL isn't
>> > available on the build platform. I'd suggest that if configure isn't
>> > given a valid OpenSSL installation (or can't find one), then we just
>> > disable all the tunnelling options - just surround the appropriate
>> > code in #ifdef OPENSSL or something and hide the tab on dlgServer.
>>
>> Hmm. But couldn't we still support tunneling with passwords, just not
>> publickey? If so, I'd much rather see just that option grayed out
>> (maybe have a text that says why, if there's room) than to remove the
>> complete functionality. I know lots of people who use ssh with
>> passwords only (e.g. LDAP integrations etc), that could benefit from
>> this even if it doesn't come with key support.
>>
> I would prefer to have that feature which supplies of private and public
> keys both or with password.
> But - as libssh2 requires either openssl or libgcrypt.
> If none found on the system, we can disable this feature.
>

Good point - we could have configure look for OpenSSL, if that's not
found, look for gcrypt (and require the user to provide a public key to use
a tunnel), or finally if neither are found, disable the tunnelling feature
altogether.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company