build: remove OSX deprecated warnings for openssl
known_hosts: add ssh_knownhosts_algorithms()

Goal of that function is to test the preferred key exchange methods
based on what's available in the known_hosts file

Conflicts:
	tests/client/torture_knownhosts.c
knownhosts: add test case for bug #138
Knownhosts: implement hostkey with knownhosts heuristic
server: allow custom server banners (bug #83)
server: use custom server banners

Value of session->serverbanner never gets used

Signed-off-by: Audrius Butkevicius <audrius.butkevicius@gmail.com>
Kex: fix coverity warning + edge case
tests: lines lost during last cherry-pick merge
knownhosts: detect variations of ecdsa
knownhosts: resolve leaks found by coverity
Revert f2c2687ca6c6c7e25c9a547227027ab28eb4fc16

Fix bug #142
The mode does need to be an octal numeric string. Mode 0600 now gets sent on the wire as 0384, triggering a "scp: protocol error: bad mode" response, and an "scp status code 1d not valid" message from libssh.
session: add getters for session cipher names

Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
session: skip timestamp init for non-blocking case

Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
build: Use Threads_FOUND to decide whether to build ssh_threads.

Follow-up to 4e04ec8, which caused a regression on OS X.

Checking the value of CMAKE_THREAD_LIBS_INIT to decide whether any threading
library is present on a system turns out to be wrong -- in OS X, for
example, usage of pthreads does not depend on any additional linker or
compiler flags, so CMAKE_THREAD_LIBS_INIT is empty and our check in
src/CMakeLists.txt failed (it used to work before 4e04ec8 because
CMAKE_HAVE_THREADS_LIBRARY is set).

Instead, just look for Threads_FOUND, which FindThreads sets just like any
other Find module when it has found what it was looking for.

Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
packet: Do not decrypt zero length rest of buffer

If we receive a packet of length exactly blocksize, then
packet_decrypt gets called on a buffer of size 0.  The check at the
beginning of packet_decrypt indicates that the function should be
called on buffers of at least one blocksize, though the check allows
through zero length.  As is packet_decrypt can return -1 when len is 0
because malloc can return NULL in this case: according to the ISO C
standard, malloc is free to return NULL or a pointer that can be freed
when size == 0, and uclibc by default will return NULL here (in
"non-glibc-compatible" mode).  The net result is that when using
uclibc connections with libssh can anomalously fail.

Alternatively, packet_decrypt (and probably packet_encrypt for
consistency) could be made to always succeed on len == 0 without
depending on the behavior of malloc.

Thanks to Josh Berlin for bringing conneciton failures with uclibc to
my attention.

Signed-off-by: Alan Dunn <amdunn@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
packet_crypt: Make packet_{en,de}crypt fail consistently on len == 0

Right now the behavior of packet_{en,de}crypt on len == 0 depends on
the behavior of malloc.  Instead, make these consistently fail based
on what I assume the desired behavior is due to the first error
message in each.

Signed-off-by: Alan Dunn <amdunn@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
packet: Improve readablity of packet decrypt.

After discussion with Aris and it was not obvious enough to understand
the issue we decided to refactor it.

Reviewd-by: Aris Adamantiadis <aris@0xbadc0de.be>