Re: SSH Tunneling implementation

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: SSH Tunneling implementation
Date: 2012-07-13 09:15:13
Message-ID: CABUevEzLVetY6NO-AEfeXBzaRzRF4VGOiZKfYboirzcHxY3G8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Ashesh Vashi 2012-07-13 09:24:54 Re: SSH Tunneling implementation
Previous Message Dave Page 2012-07-13 08:32:10 Re: SSH Tunneling implementation