Previously, the last two fields of KEXINIT were considered as always zero for
the key exchange. This was true for the sending side, but might have not been
true for the received KEXINIT from the peer.
This moves the construction of these two fields closer to their reading or
writing, instead of hardcoding them on the last possible moment before they go
as input to the hashing function.
This also allows accepting the first_kex_packet_follows on the client side, even
though there is no kex algorithm now that would allow this.
It also avoid memory leaks in case the server_set_kex() or ssh_set_client_kex()
gets called multiple times, ensuring the algorithms will not change under our
hands.
It also makes use of a new flag to track if we sent KEXINIT.
Previously, this was tracked only implicitly by the content of the
session->next_crypto->{server,client}_kex (local kex). If it was not set, we
considered it was not send. But given that we need to check the local kex even
before sending it when we receive first_kex_packet_follows flag in the KEXINIT,
this can no longer be used.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The information if the session is client or server session is already part of
the session structure so this argument only duplicated information.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Solving issue #110. The original work is at !231
Some changes were needed because the newly added features in master through time
Signed-off-by: Mohammad Shehar Yaar Tausif <sheharyaar48@gmail.com>
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
These features allow for options Ciphers, HostKeyAlgorithms, KexAlgorithms and
MACs to append, remove and prepend to the default list of algorithms
respectively
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
uint32_t should be formated by PRI?32
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Change-Id: I811cfd764010f9e8bb599b370155ac065ee1905c
Loglevel INFO is the default openssh configuration setting which does not print
redundant information. On a system using openssh with loglevels set by the
terms of openssh will cause unwanted log lines in the output.
recategorized based on - SSH_LOG_DEBUG are informational debug logs (no error)
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
According to the documentation the return value is the number of
processed bytes, so the returned value is never negative. We should not
use ssize_t in public headers as it isn't available on Windows! We only
have it defined in priv.h!
Signed-off-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>
Previously, there was non-consistent usage of constans SSH_KEX_METHODS,
KEX_METHODS_SIZE and of magic number 10 to reference the arrays used
for algorithm negotiation by peers. This commit settles down to the single
constant and its usage throughout the whole codebase.
Fixes T195
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Generally, when the extension negotiation is enabled and client supports
SHA2 algorithms for RSA, they are supposed to be prioritized against the
old SHA1. If it is not (ssh-rsa is listed in front of rsa-sha2-* hostkey
algorithms during negotiation), the server wrongly tries to provide the
new typo of signature, ignoring the negotiated algirithm
This commit propagates the digest algorithm from negotiation to the actual
signature functions, which were previously responsible for decision
about the hash algorithm based just on the negotiated extensions.
Fixes T191
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Send only allowed algorithms in server-sig-algs extension if in FIPS
mode.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
When in FIPS mode, filter the algorithms to enable only the allowed
ones. If any algorithm is explicitly set through options or
configuration file, they are kept.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Previously, when no methods were set, the server would enable all
supported methods. This changes this behaviour by setting only the
default methods.
The server in pkd_daemon.c was changed to set explicitly all the
supported methods to keep the previous behaviour.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The added option SSH_BIND_OPTIONS_HOSTKEY_ALGORITHMS allows restricting
the signature algorithms to offer to the client for host authentication.
The list set is used as a filter of allowed algorithms.
First a list of possible signature algorithms to offer is created from
the keys set and then such list is filtered against the allowed
algorithms.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The added option SSH_BIND_OPTIONS_PUBKEY_ACCEPTED_KEY_TYPES allows
restricting the allowed public key types accepted by the server for
authentication.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Fix libssh server sending SSH_MSG_EXT_INFO messages upon rekey: clients
do not expect that message during rekey, and OpenSSH in particular will
log error messages along the lines of:
"kex protocol error: type 7 seq 15"
when the message is received during a rekey.
To fix, check against the session connected flag, which only transitions
to non-zero following the first successful authentication.
bf2c7128ab adds logic to resolve this
issue, but it turns out that checking the session_state to avoid
sending the message is insufficient, because that state is re-set
to SSH_SESSION_STATE_KEXINIT_RECEIVED during rekey.
The before-and-after effects of this change can be observed using the
pkd --rekey flag as so:
./pkd_hello -t torture_pkd_openssh_rsa_rsa_sha2_256 \
-i1 --rekey=16 -v -v -v 2>&1 |
grep -e 'KEY' -e 'EXT'
^ where before the change, multiple SSH_MSG_EXT_INFO send messages are
logged; after, there is only a single SSH_MSG_EXT_INFO logged once upon
the first initial key exchange.
Cross-reference: https://bugs.libssh.org/T121.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Fix a bug with server-side rekeying where the session state at hand
has been toggled to SSH_SESSION_STATE_AUTHENTICATED before performing
the packet send of the SSH2_MSG_USERAUTH_SUCCESS message.
Before this change, what can happen is that during the packet send,
the SSH2_MSG_USERAUTH_SUCCESS message can end up being queued due
to a small rekey data limit value. libssh server will then proceed
to attempt to send KEX-related rekeying messages to the client before
the client has received USERAUTH_SUCCESS. OpenSSH clients do not
expect to undergo rekeying before having been authenticated, and so
will exit with error when this happens.
The behavior before and after can be observed with the pkd test making
use of its new --rekey flag:
./pkd_hello -t torture_pkd_openssh_rsa_rsa_default -i1 --rekey=16 -v -v -v
A new CMake test entry is added for the above variation and can be run
with:
ARGS="-R pkd_hello_rekey" make test
Before the fix, the test will fail; after, the test succeeds while
performing rekeying once every 16 bytes.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This type is imprecise. We often need the ecdsa_nid in addition to the key type
in order to do anything. We replace this singluar ECDSA type with one type per
curve.
Signed-off-by: Ben Toews <mastahyeti@gmail.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
If the server had an RSA host key, it provided unconditionally SHA2
signatures without consulting the client proposed list of supported host
keys.
This commit implements more fine-grained detection of the extension
to provide the client with valid signatures according to RFC 8332
Section 3.1.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The default rekeying recommendations are specified in
RFC4344 Section 3 (First and Second Rekeying Recommendations).
Additionally, the rekeying can be specified in configuration
file/options allowing us to turn the rekeying off, base it
on time or make it more strict.
The code is highly inspired by the OpenSSH rekeying code.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
And remove most of the direct access to the structure throughout the code
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This should not be a problem for well-behaving clients that do not
append the ext-info-c to the rekey, but if they do, we should not
send it either.
Resolves: T121
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
ssh_send_keepalive() should use global_request() to properly configure
the state machine for packet filtering.
Signed-off-by: Nicolas Viennot <nicolas@viennot.biz>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The SHA2 variants should be preferred. Also the buffer needs to be
extended to fit all possible public key algorithms.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This includes intercepting the ext-info-c string from
the client kex proposal, configuring the server to allow using
this extension and sending the SSH_MSG_EXT_INFO packet back
to the client after the new keys are in use.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
