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.
Great!
> 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
matters.
> 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.
http://www.libssh2.org/mail/libssh2-devel-archive-2010-06/0155.shtml
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-07-02