Currently Compression=no (the default) force-disables zlib algos, while
Compression=yes force-enables it. This means that mismatching options between
client and server lead to connection failure. This can easily happen if the
server has default settings but the client specifies Compression=yes.
OpenSSH treats the option as a "prefer compression" setting:
Compression=no -> none,zlib@openssh.com,zlib (default)
Compression=yes -> zlib@openssh.com,zlib,none
This commit changes the libssh behaviour to the same as OpenSSH.
Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
RFC 4252 §7 states that the public key algorithm in a
SSH_MSG_USERAUTH_PK_OK response is the public key algorithm name from
the request. When using RSA with SHA-2, this will be either
"rsa-sha2-256" or "rsa-sha2-512" as specified by RFC 8332 §3.2.
However, currently libssh emits the public key type instead, which is
"ssh-rsa". This is not in conformance with the RFCs, so let's fix this
by storing the signature type and emitting it in our response instead of
the public key when sending SSH_MSG_USERAUTH_PK_OK in the server.
Signed-off-by: brian m. carlson <bk2204@github.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Similarly as we already have for the client configuraiton file
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Calling some channel procedures on a freed channel is always resulting
in segmentation fault errors. The reason is that when a channel is
freed with 'ssh_channel_do_free' procedure, its 'session' field is set
to NULL; then when a channel procedure tries to access any field of
'channel->session' structure it is effectively dereferencing a NULL
pointer.
The change fixes that behavior by adding a check which ensures that a
channel state is not SSH_CHANNEL_FLAG_FREED_LOCAL before accessing its
parent session.
Also the test suite is updated to check for the fixed errors, and the
Doxygen documentation updated accordingly.
There was a bug introduced in b0fb7d15: 'ssh_channel_poll',
'ssh_channel_poll_timeout' and 'ssh_channel_get_exit_status' would
compare the channel state to the 'SSH_CHANNEL_FLAG_FREED_LOCAL'
constant to check if the channel is alive. But the procedures must
check the channel flags for the presence of
'SSH_CHANNEL_FLAG_FREED_LOCAL' bits instead. This change fixes the
bug.
Signed-off-by: Artyom V. Poptsov <poptsov.artyom@gmail.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Normally, the length of session_id and secret_hash is the same,
but if we will get into rekeying with a peer that changes preference
of key exchange algorithm, the new secret hash can be larger or
smaller than the previous session_id causing invalid reads or writes.
Resolves https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35485
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
and add LOG_SIZE macro to control the buffer size
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: I3eaeea001fc531fdb55074fc3a9d140b27847c1f
since ssh_scp_deny_request is seldom called, let's
utilize malloc to reserve the precise size memory.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: I8e7a6d3153cff7691329b9487cd534a7f2887a35
to avoid allocate 4KB buffer from stack
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: Id144ff764ee1ae98f87aee36793a9f0e4fce21b7
to avoid allocate 16KB buffer from stack and one memory copy
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: Ib71cb5834b7810bf9791e13c58571e2b9fa5bca1
to avoid allocate 8KB buffer from stack
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: Ifc198705cb8ecec6f0a609f84965382dc151693b
to reduce the stack size requirement
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: I6a91250524786af3358b0fd0f05ba8e45f76d278
to avoid their prototype different from ssh_cipher_struct
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: I6cba2d4fea131f13d028226023da692494caa87d
This started failing CI on Fedora with new GCC
/builds/jjelen/libssh-mirror/src/external/ed25519.c:80:48: error: argument 1 of type 'unsigned char *' declared as a pointer [-Werror=array-parameter=]
80 | int crypto_sign_ed25519_keypair(unsigned char *pk,
| ~~~~~~~~~~~~~~~^~
In file included from /builds/jjelen/libssh-mirror/src/external/ed25519.c:15:
/builds/jjelen/libssh-mirror/include/libssh/ed25519.h:46:48: note: previously declared as an array 'uint8_t[32]' {aka 'unsigned char[32]'}
46 | int crypto_sign_ed25519_keypair(ed25519_pubkey pk, ed25519_privkey sk);
| ~~~~~~~~~~~~~~~^~
/builds/jjelen/libssh-mirror/src/external/ed25519.c:81:48: error: argument 2 of type 'unsigned char *' declared as a pointer [-Werror=array-parameter=]
81 | unsigned char *sk)
| ~~~~~~~~~~~~~~~^~
In file included from /builds/jjelen/libssh-mirror/src/external/ed25519.c:15:
/builds/jjelen/libssh-mirror/include/libssh/ed25519.h:46:68: note: previously declared as an array 'uint8_t[64]' {aka 'unsigned char[64]'}
46 | int crypto_sign_ed25519_keypair(ed25519_pubkey pk, ed25519_privkey sk);
| ~~~~~~~~~~~~~~~~^~
/builds/jjelen/libssh-mirror/src/external/ed25519.c:117:46: error: argument 5 of type 'const unsigned char *' declared as a pointer [-Werror=array-parameter=]
117 | const unsigned char *sk)
| ~~~~~~~~~~~~~~~~~~~~~^~
In file included from /builds/jjelen/libssh-mirror/src/external/ed25519.c:15:
/builds/jjelen/libssh-mirror/include/libssh/ed25519.h:61:27: note: previously declared as an array 'const uint8_t[64]' {aka 'const unsigned char[64]'}
61 | const ed25519_privkey sk);
| ~~~~~~~~~~~~~~~~~~~~~~^~
/builds/jjelen/libssh-mirror/src/external/ed25519.c:180:51: error: argument 5 of type 'const unsigned char *' declared as a pointer [-Werror=array-parameter=]
180 | const unsigned char *pk)
| ~~~~~~~~~~~~~~~~~~~~~^~
In file included from /builds/jjelen/libssh-mirror/src/external/ed25519.c:15:
/builds/jjelen/libssh-mirror/include/libssh/ed25519.h:76:26: note: previously declared as an array 'const uint8_t[32]' {aka 'const unsigned char[32]'}
76 | const ed25519_pubkey pk);
| ~~~~~~~~~~~~~~~~~~~~~^~
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Sahana Prasad <sahana@redhat.com>
to avoid their prototype different from ssh_cipher_struct
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Sahana Prasad <sahana@redhat.com>
Change-Id: I6cba2d4fea131f13d028226023da692494caa87d
Due to the missing include, the compiler makes assumptions and leads to
a crash in ssh_mutex_lock() during runtime.
Signed-off-by: Chris Townsend <christopher.townsend@canonical.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Calling set_target_properties directly overrides previously set flags,
so replace them with target_compile_definitions and target_link_options.
Signed-off-by: DDoSolitary <DDoSolitary@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Previously, the mbed TLS implementation wouldn't be use at all when
available, being the internal implementation always used instead.
This corrects few bugs and makes the mbed TLS implementation to be used
when ChaCha20 and Poly1305 are available.
This also makes the constant time comparison to be used when checking
the authentication tag.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
When checking the authentication tag, use secure_memcmp() instead of
memcmp().
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
When comparing the authentication tag for chacha20-poly1305, use the
constant time CRYPTO_memcmp() instead of memcmp().
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
