Re: 0.9.3 version regressions

[Jakub Jelen <jjelen@xxxxxxxxxx>]

On Thu, 2020-01-02 at 17:03 +0100, Michal Vaško wrote:
> Hello,
> we have been experiencing some major behavior changes compared to
> previous versions (0.9.2 still worked fine) and I would really
> appreciate some help because I have tried debugging these problems
> without much success.
> 
> 1)
> We have a test where an SSH key is used for authentication. Some time
> ago it stopped working because "ssh-dss" key type was no longer
> accepted by default (at least that was my conclusion) so a call
> 
> ssh_options_set(session, SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES, "ssh-
> ed25519,ecdsa-sha2-nistp256,"
>             "ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,rsa-
> sha2-512,rsa-sha2-256,ssh-dss");
> 
> was added (to allow all publickey types) and the problem was fixed.
> After updating to libssh 0.9.3, however, this problem appeared again.
> After some trial-and-error debugging I have learned that if I set the
> aforementioned options before ssh_connect(), they get reset and the
> problem disappeared when I put this call after ssh_connect(). Was
> this, by any chance, an intentional change?

Around the call to connect(), libssh reads configuration files (I think
since 0.9.0). If some of the configuration files lists this
configuration option or libssh is configured to read some particular
other file at build time. This can happen.

You can use SSH_OPTIONS_PROCESS_CONFIG to suppress processing of any
configuration file if it is not desirable to do so (using libssh to
single task connecting to single host).

Since this is related to Fedora 31+, I think it is some change in the
default crypto policies or something tied to Fedora.

Why do you need DSA keys anyway?

For the poll issue, I will have to check what actually changed around
there. But as I am not familiar with Suse nor Debian, it could even be
some change in underlying system.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.