On Wed, May 21, 2025 at 1:43 PM <g4-l...@tonarchiv.ch> wrote: > Hi > On 5/21/25 09:44, Jakub Jelen wrote: > > Hi, > the strace does not show much what libssh does. > > It just confirms the check is failing locally, without sending the public > key to server. But the signature algorithm depends on the extensions > negotiated during key exchange, which should be logged in verbose log. > > I meant setting the log level using something like this: > > int verbosity = SSH_LOG_TRACE; > ssh_options_set(session, SSH_OPTIONS_LOG_VERBOSITY, &verbosity); > > Ah sure, but you don't need strace to read the log ;) I disabled it on > purpose so you see the essential filehandling... > > Here you go again (attached). >
I think this was still log level 3, while to get all of the tracing information and packet numbers, log level 4 is required. I am still trying to figure out if the extensions are negotiated and sent correctly to see if it is server or client issue. This is still not visible from this log. I think the code to handle this is already in 0.9.7, but it might be also affected by some configuration/options on the server side. > It is also possible that the global configuration from cryptographic > policies overrides the `SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES`. The strace > log shows that the OpenSSH configuration is read before connecting: > > openat(AT_FDCWD, "/etc/crypto-policies/back-ends/openssh.config", > O_RDONLY) = 5 > > This file does not have the ssh-rsa (SHA1) mechanisms in accepted types: > > $ cat /etc/crypto-policies/back-ends/openssh.config | grep ssh-rsa > > If this is the case, is there a option to keep libssh from reading > systemwide configs? In my case that would be neater than enabling SHA for > the whole system... > There is SSH_OPTIONS_PROCESS_CONFIG in ssh_options_set(), which if set to false, will not process any system configuration. https://api.libssh.org/master/group__libssh__session.html#ga7a801b85800baa3f4e16f5b47db0a73d Jakub
