Re: SSH Tunneling implementation

On Tue, Jul 10, 2012 at 4:33 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Tue, Jul 10, 2012 at 11:57 AM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> > On Tue, Jul 10, 2012 at 12:52 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >> On Tue, Jul 10, 2012 at 11:39 AM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> >>> Can we identify which version of libssh is required, and have a
> >>> configure check for it? AFAICT they are all on 1.2 until the *next*
> >>> release - so is it really something that breaks on just a minor
> >>> version? If so, we really need a configure check for it.
> >>>
> >>> I think it's ok to say that we can't build with that feature on 10.04
> >>> (assuming we can find a configure test for it). less sure about
> >>> something that's less than a year old such as 11.10.
> >>
> >> Yeah, that seems reasonable. I'd also suggest pinging the libssh2
> >> mailing lists to see if there's another API that you've missed, or if
> >> they can explain why it's necessary to provide the public key and
> >> private one.
> >>
> >> So... something to think about in parallel with that; if we cannot
> >> deal with this cleanly using libssh2, should we go back to the
> >> original plan that Akshay and I discussed privately, which was to have
> >> pgAdmin spawn ssh (or putty on Windows) processes to provide the
> >> tunnels?
> >
> > Ugh. That seems pretty painful. Particularly on windows where you're
> > going to end up with an actual window (whether hidden or not).
>
> It's ugly, but not necessarily painful. We have existing code for
> finding executables and running them. And putty does have a tunnel app
> which is (I believe), windowless.
>
Why are we talking about using the external application here?
The only problem with the current implementation - is that it does use new
APIs for tunneling.
We can change the implementation based on the current supplied libssh2 on
most linux flavours.
i.e. libssh2 - 1.2.7 or later

I have asked Akshay to check - if we can modify the current implementation
to use the older version of libssh2. (feasibility)

--

Thanks & Regards,

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

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

>
> > I'd
> > definitely suggest putting more effort into getting it working with
> > libssh2 first. Absolute worst-case, maybe embed a verison of libssh
> > inside pgadmin and use static linking until we hit more modern
> > platforms? I don't believe it's that big...
>
> Right - and the licence is agreeable. At least that way we could more
> easily tell what encryption library we're using, and show/hide the
> public key option as appropriate.
>
> > (But yes, first try the list for it. And if you don't get responses
> > there (at all), let me know and I'll bug some of the people - while I
> > haven't used it myself, I do know at least one of those developers
> > pretty well)
>
> Oh, you do? Handy...
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> 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
>