Subject: Re: libssh2: Ported to UC Linux ?

Re: libssh2: Ported to UC Linux ?

From: Peter Stuge <>
Date: Fri, 2 Jul 2010 09:35:40 +0200

Hi Paul,

Paul Romero wrote:
> First, thank you for the quick and detailed reply and be assured
> the difference between SSH and SASL is clear to me.


> Also, I must emphasize that my interest is in the SSH-2 component
> subset required to support SFTP rather than SSH.

Ah, sorry for being a bit sloppy with terminology. These days SSH
version 1 is not in wide use anymore, so I tend to put SSH = SSH
version 2 always. libssh2 only supports SSH version 2.

> I think the SASL version of libgcrypt meets the minimum libssh2
> requirements, and that AES and RIJNDAEL are the same.

That's correct.

> Also, I assume that libssh2 can use DES and 3DES interchangeably.

They are distinct algorithms, and SSH requires 3DES. Several
algorithms are OPTIONAL in the standard, including AES/RIJNDAEL,
although it is listed as RECOMMENDED and aes128-ctr, aes192-ctr and
aes256-ctr is likely to become REQUIRED in the future so I always
strongly recommend that they be included.

> It appears most SFTP implementations also use the following:
> Diffie Hellman-SHA1, Blowfish, Twofish, HMAC-SHA1 and HMAC-MD5.
> Do you think that is correct ?

DH-SHA1 and HMAC-SHA1 are also REQUIRED, the others are optional. SSH
handles negotiation at connect time to the prefered algorithms
supported by both client and server.

> The reason I mentioned SASL is the version GSASL I am using came with
> a version of libgcrypt. However, I am not sure if libgcrypt is part
> of the GSASL package or it came from elsewhere.

libgcrypt is always it's own package. Good news.

> In any case, assuming a version of libgcrypt that supplies what
> libssh2 needs is found, libssh2 and libgcrypt can easily be linked
> together. Is that correct ?

Yes, you select if you want to use libgcrypt or OpenSSL when you run
configure for libssh2.

> You seem to suggest that compiling libssh2 requires modern automake
> capabilities.

I don't think it does actually, and even if it did, I wanted to point
out that it's not a problem, since autotools are not a part of the
toolchain and could thus be updated to the very latest version
without problems, should that be required.

> Using a newer version of the GNU ELF Toolchain may solve that
> problem for me--cross compilers etc. But, migrating to a newer
> UC Linux version is not an option. Would this be a barrier to using
> libssh2 ?

No. As long as you have a working GNU toolchain for your target and
a sane /bin/sh then you will be fine.

> (i.e. I am sure the GNU toolchain I am using does not have modern
> automake capabilities.)

Again, please don't connect those two. autotools (slang for
autoconf+automake) is independent, only ever required natively on the
host machine, and actually you don't need it unless you want to try
to build libssh2 with your own source code modifications.

> Note that the UC Linux Makefile scheme, and where and how
> libraries are linked is quite different than in standard Linux.

The binaries and libraries, which is what matters for libssh2, are
quite likely built using totally standard cross-compiler techniques,
since you have a GNU toolchain. That's really the only point that

> In addition there are differences in how forking and exits work
> despite the fact the kernel API is the same.

True! However libssh2 never forks, so no issue.

> Most of the "porting" I mentioned consists of creating Makefiles
> that fit within the UC Linux scheme which is not a huge effort but
> certainly not trivial.

I don't know what these special Makefiles are that you mention, and I
believe that you can simply cross-compile libssh2 using your
toolchain for this target, in the standard way.

Make sure the toolchain programs are included in your PATH, and use
the --host=tuple parameter when configuring libssh2. Substitute tuple
with the prefix for your toolchain, so if your toolchain provides
m68k-elf-gcc, then run configure --host=m68k-elf and include the
library paths needed.

I recently described how I successfuly cross-compiled libssh2 for
Windows and you can use the same procedure if you substitute my
i686-mingw32 for m68k-elf or the appropriate prefix, and of course
the paths to where your libraries and headers are.

Received on 2010-07-02