That should not be the case. The server should be sending this message from the `session->ssh_connection_callback` so unless you override that one, it should be executed (and that one is not designed to be overridden).
Can you get the debug logs from the server for one connection to see what is going on there? Jakub On Thu, May 22, 2025 at 11:34 PM <g4-l...@tonarchiv.ch> wrote: > On 5/22/25 12:38, Jakub Jelen wrote: > > On Wed, May 21, 2025 at 4:26 PM <g4-l...@tonarchiv.ch> wrote: > >> On 5/21/25 15:53, Jakub Jelen wrote: >> >> >> 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'm confused about how ssh_options_set(session, >> SSH_OPTIONS_LOG_VERBOSITY, ...) and ssh_set_log_level() is connected. >> >> I used ssh_set_log_level(SSH_LOG_PACKET) - this is not equal to >> ssh_options_set() with SSH_LOG_TRACE? >> > > Sorry, the names are a bit confusing. The SSH_LOG_PACKET = SSH_LOG_DEBUG > is 3, while SSH_LOG_TRACE = SSH_LOG_FUNCTIONS is 4. These aliased names > have quite conflicting descriptions (and I am not even sure why we have > them twice). It would be good to make it a bit more systematic ... > > My bad, for some reason I put SSH_LOG_PACKET instead of SSH_LOG_FUNCTIONS. > > Yes I was always wondering why there are these two different naming > schemes... Maybe there were plans to have some kind of scopes besides the > levels. > > > > >> Ah wait I see the issue: I called ssh_set_log_level() after ssh_new(). I >> guess that makes the difference. >> >> New log attached. >> >> >> 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 >> >> Yes! That did the trick: >> >> [2025/05/21 16:16:49.030307, 3] ssh_packet_need_rekey: rekey: >> [data_rekey_needed=0, out_blocks=61, in_blocks=45] >> [2025/05/21 16:16:49.030405, 2] ssh_userauth_publickey_auto: >> Successfully authenticated using /home/useruser/id_rsa >> Connected and authenticated with key! >> >> Cheers >> Till >> > Good to hear it worked. > > Looking at the log, I see the client correctly advertises the support for > the extensions: > > [2025/05/21 16:12:17.052133, 4] ssh_list_kex: kex algos: > curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ext-info-c > > > But I do not see the server sending the SSH_MSG_EXT_INFO packet (RFC 8308) > so its likely the server to blame for this issue. Updating to newer libssh > would be good to get the newer functionality and bugfixes. > > I wrote the server 6 (?) years ago... But looking at the sources of > libbssh 0.9.7 I can find the handling of SSH_MSG_EXT_INFO in > ssh_server_connection_callback() (server.c:431). > > Maybe I overwrote the callback? I set the server callbacks here: > > struct ssh_server_callbacks_struct cb = { > .userdata = &info, > #ifdef WITH_PASSWORD > .auth_password_function = auth_password, > #endif > #ifdef WITH_GSSAPI > .auth_gssapi_mic_function = auth_gssapi_mic, > #endif > #ifdef WITH_PUBKEY > .auth_pubkey_function = auth_publickey, > #endif > .channel_open_request_session_function = new_session_channel, > .service_request_function = service_request > }; > > All other custom callback functions are on channel level... > > Wait, there's also a custom message_callback(). But this only handles > ssh_message_type(message) == SSH_REQUEST_CHANNEL_OPEN. In any other case it > returns 1 (hence the lib should handle all other messages). > > Cheers, > Till > > >
