Skip site navigation (1) Skip section navigation (2)

Re: SSH Tunneling implementation

From: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, 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:24:54
Message-ID: CAG7mmoz_jdk5iZLQONtJSn=WzK7U9wzKSbYT3VA9ZTqvgJ+U1A@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
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.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com/>


*http://www.linkedin.com/in/asheshvashi*

>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

In response to

Responses

pgadmin-hackers by date

Next:From: Dave PageDate: 2012-07-13 09:53:38
Subject: Re: SSH Tunneling implementation
Previous:From: Magnus HaganderDate: 2012-07-13 09:15:13
Subject: Re: SSH Tunneling implementation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group