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
