RHEL 5 and problem with curl dependencies (libssh2 1.2.8)

Latest response

Hi, Apologies if I'm asking something real stupid, or asking in the wrong place - "I'm new here" as they say. I have a customer who is required to upgrade their production application. As part of this, the supplier has specified that curl needs upgrading to 7.21.x (currently they're on 7.16.1-1.1 I've downloaded the relevant rpm and found the yum install failed with dependency upon libcurl also being upgraded to version 7.21.x - so I duly downloaded that rpm too! You guessed? It still fails - this time asking for libssh2 to be version 1.2.8 or later. Herein seems to lie my problem. libssh2 1.2.8 is a pretty recent release, and I've only so far found one place to get a rpm file for it - via the 'pbone' site. So far so good I thought! Ahh no! Now it's complaining that the libssh2 rpm package is 'signed' and I need to get a key ... and my grand question ... how can I get this, given it doesn't seem to be listed anywhere on any sites? I've also now tried downloading the source for libssh2 1.2.8 - but then ran into next stumbling block ... I don't have any C/C++,etc, compilers installed anywhere, so this seems to be a non-starter too :-( I'm pretty much open to suggestions from my peers now as to how I might go about sorting this out. Your comments/suggestions would be very welcome. (And just before anyone asks if I've placed a call with RH support - yes - they've spent the week looking into the problem before declaring "libssh2 is not from us, so you're not supported".) Thanks Paul


pbone should have a key for RPMs that they package and distribute. If they are mirroring another distribution's packages, you will need to grab the appropriate distribution's key.

If possible, please post the full path to the libssh2 package you downloaded, and the full error message when attempting to install the package.

BTW: you may also be able to use the --nosignature option when installing the RPM to not verify package or header signatures to skip the check. I wouldn't advise this on a production host, however.

I would strongly suggest testing any external packages in a development or staging environment before deploying to production, especially as this software would be unsupported by Red Hat.