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
