The libssh versions before this included files with relative path based
on the current working directory, which can result unexpected results
and is different from the OpenSSH include behavior. The manual page for
ssh_config lists:
> iles without absolute paths are assumed to be in ~/.ssh if included in
> a user configuration file or /etc/ssh if included from the system
> configuration file.
This is following the semantics as close as possible with a difference
that we do not use the hardcoded ~/.ssh for user configuration files,
but the path defined with SSH_OPTIONS_SSH_DIR, which is already used
to reference any other files in used home directory.
Fixes#93
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This fails if the gethostname() fails in a way that does not write the
buffer, but returns 0 as a success.
Fixes#106
Thanks oss-fuzz
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Sahana Prasad <sahana@redhat.com>
This prevents the usage of uninitialized value on error in the known
hosts hasing code if invalid (empty) hostname is used.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Sahana Prasad <sahana@redhat.com>
The adjacent question marks and asterisks can be simplified to single
wildcard so there is no need to excersise all the recursive pattern
matching.
These inputs were generated by oss-fuzz and probably caused also the
previously reported timeouts.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This is more than enough as it reflects to 16 asterisks in the match
string is more than enough. With larger values oss-fuzz was generating
long match strings with asterisks interleaved with normal characters,
which were timing out.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
In certificate authentication with OpenSSH 8.0, the SHA2 signatures were
not accepted correctly [1]. This was not an issue up until the OpenSSH
8.8p1, which does no longer allow SHA1 signatures by default so this
broke the CI and tests against the new OpenSSH [2].
Fixes!107
[1] https://bugzilla.mindrot.org/show_bug.cgi?id=3016
[2] https://gitlab.com/libssh/libssh-mirror/-/issues/107
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
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>
Do not compile tests which need SSHD_EXECUTABLE when
it is not available
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
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>
We do not use SHA1 as it is disabled in many systems
Verifies CVE-2021-3634
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
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>
Covscan analyzer was used
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-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
