This prevents code injection.
The domain name syntax checker is based on RFC1035.
Signed-off-by: Norbert Pocs <norbertpocs0@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
The hostname can be a domain name or an ip address. The colon has to be
allowed because of IPv6 even it is prohibited in domain names.
Signed-off-by: Norbert Pocs <norbertpocs0@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Using ssh_config_parse_uri can simplify the parsing of the host
parsing inside the function of ssh_options_set
Signed-off-by: Norbert Pocs <norbertpocs0@gmail.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Some architectures (s390x) provide different poll events such as POLLHUP in case
the remote end closed the connection (and they keep reporting this forever).
This is an issue when the user provided callback registering this event as an
error and tries to send some reply (for example EOF) using
`ssh_channel_send_eof()` which will lead to infinite recursion and sefgaults.
This was not solved by the 30b5a2e33b because the
POLLHUP event is not provided by the poll in events bitfield, but only reported
by the poll in revents bit field thus we need to filter these events later on
when the poll is recursively.
Fixes#202
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
(cherry picked from commit 4e56c5c956)
The FD locking was modified in 30b5a2e33b but it
caused some weird issues on s390x in Debian tests, which were getting POLLHUP,
causing infinite recursion while the callback tried to close socket.
Previously, the lock blocked only the POLLIN events as we believed these were
the only events we could get recursively that could cause issues. But it looks
like more sane behavior will be blocking everything but POLLOUT to allow the
buffers to be flushed.
Fixes#202
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
(cherry picked from commit f86bec735b)
Use the new `-L` flag for the pkd tests so that they use a
unique temporary directory for scratch space while running.
Note the choice of `pkd_scratch_XXXXXX` in contrast to a
path living under `/tmp`: by using a relative path, one can
gather the full set of log artifacts from the GitLab CI jobs
in the event that there is a test failure. The logs contain
lots of information to help pinpoint what went wrong.
Resolves https://gitlab.com/libssh/libssh-mirror/-/issues/143.
Testing notes:
- In the GitLab CI jobs I can see the flag being used, and
can observe that I am able to gather the full set of
detailed `pkd` logs in the event of a legitimate test
failure.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
(cherry picked from commit 4f6aa53b16)
Teach `pkd` a new flag `-L, --temp-dir=<mkdtemp-template>` to enable
behavior whereby `pkd` creates a new temporary directory and uses it
for a workspace while running.
The original design of `pkd` assumed that it could freely use the
current working directory from wherever it happened to be invoked.
But, this could pose a problem when multiple `pkd` instances are run
in parallel from the same working directory, due to the usage of
various temporary files within that directory.
To avoid the problem of multiple `pkd` instances interfering with
each other, expose a `-L` flag for optionally specifying a `mkdtemp`
template string such that a temporary scratch space is used instead.
Testing notes:
- I ran handfuls of iterations locally using the new flag
and observed `pkd` is indeed using scratch space as desired.
Resolves https://gitlab.com/libssh/libssh-mirror/-/issues/143.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
(cherry picked from commit b610757e63)
Relax the `pthread_kill` result assertion in `pkd_stop` to tolerate
`ESRCH`, and guard against only `EINVAL` and `ENOTSUP`.
On macOS what can happen is that the `pthread_kill` returns `ESRCH` due
to the accept thread being already terminated. For that case, the
teardown path should proceed to `pthread_join`.
Testing notes:
- On my macOS setup I consistently encountered `ESRCH` in this
codepath, causing pkd tests to fail unnecessarily. With the
change, I observe the tests passing.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
(cherry picked from commit aa206cbfe5)
In e1a8b359c1 a missing `free` was
added to `pkd_cleanup_socket_wrapper` to free a string allocated
for the socket wrapper directory name.
Move that `free` such that it also runs in the error-out paths in
`pkd_cleanup_socket_wrapper`, to avoid a leak in those cases, too.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
(cherry picked from commit 9514547c2a)
strtoul returns 0 if no valid character was parsed, which
can unwantedly misconfigure the options.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The return value is changed by the call to pki_key_check_hash_compatible
causing the possibility of returning SSH_OK if memory allocation error
happens later in the function.
The assignment of SSH_ERROR if the verification fails is no longer needed,
because the value of the variable is already SSH_ERROR.
Signed-off-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This was for some reason failing on CentOS 7 in 0.10 branch so bringing this to
the master too.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This is not completely straightforward as it requires us to do some state
shuffling.
We introduce internal flag that can turn this on in client side, so far for
testing only as we do not want to universally enable this. We also repurpose the
server flag indicating the guess was wrong also for the client to make desired
decisions.
If we found out our guess was wrong, we need to hope the server was able to
figure out this much, we need to revert the DH FSM state, drop the callbacks
from the "wrong" key exchange method and initiate the right one.
The server side is already tested by the pkd_hello_i1, which is executing tests
against dropbrear clients, which is using this flag by default out of the box.
Tested manually also with the pkd_hello --rekey to make sure the server is able
to handle the rekeying with all key exchange methods.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Norbert Pocs <npocs@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
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>
These will be helpful when we already sent the first key exchange packet, but we
found out that our guess was wrong and we need to initiate different key
exchange method with different callbacks.
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>
