Re: 0.9.3 version regressions

[Michal Vaško <mvasko@xxxxxxxxx>]

Hi,

> 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?

Thanks for the explanation, it also worked when I tried setting SSH_OPTIONS_PROCESS_CONFIG to false. We have used DSA keys in a test so I have switched them for ECDSA. DSA key support was kept for some platforms (OpenWRT) that may need it but they way I see it, now it is up to each system/distribution to decide what keys it wants to support so I have removed setting any of these options manually which was probably the intention.

> 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.

Thanks for that and perhaps it is so but like I said, the system poll() call behaved correctly and the whole code seemed fine to me except 0 was returned. Having fixed the previous problem it also seems to me that whenever libssh 0.9.3 was used, this poll error manifested so it should not be system-specific.

Regards,
Michal