Re: SSH Tunneling implementation - Mailing list pgadmin-hackers
From | Ashesh Vashi |
---|---|
Subject | Re: SSH Tunneling implementation |
Date | |
Msg-id | CAG7mmoz_jdk5iZLQONtJSn=WzK7U9wzKSbYT3VA9ZTqvgJ+U1A@mail.gmail.com Whole thread Raw |
In response to | Re: SSH Tunneling implementation (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: SSH Tunneling implementation
|
List | pgadmin-hackers |
On Fri, Jul 13, 2012 at 2:45 PM, Magnus Hagander <magnus@hagander.net> wrote:

Agreed. It seems libssh2 is just a little bit "too new" (IIRC it'sOn Fri, Jul 13, 2012 at 10:32 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Fri, Jul 13, 2012 at 7:57 AM, Akshay Joshi
> <akshay.joshi@enterprisedb.com> wrote:
>>
>>
>> On Thu, Jul 12, 2012 at 5:44 PM, Magnus Hagander <magnus@hagander.net>
>> wrote:
>>>
>>> On Thu, Jul 12, 2012 at 2:06 PM, Akshay Joshi
>>> <akshay.joshi@enterprisedb.com> wrote:
>>> >
>>> >
>>> > On Thu, Jul 12, 2012 at 5:21 PM, Dave Page <dpage@pgadmin.org> wrote:
>>> >>
>>> >> On Thu, Jul 12, 2012 at 12:04 PM, Akshay Joshi
>>> >> <akshay.joshi@enterprisedb.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.
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..Hmm. But couldn't we still support tunneling with passwords, just not
> 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.
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.
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
pgadmin-hackers by date: