Hi Jakub Yes, this did the trick!
But to be honest I would rather say that this is a bug in the library... If I understand it right, it sends the request but doesn't take it into account before trying any authentication - is this in the SSH specs? IMHO this doesn't make much sense. Cheers Till May 27, 2025 10:15 AM, "Jakub Jelen" <jje...@redhat.com (mailto:jje...@redhat.com?to=%22Jakub%20Jelen%22%20<jje...@redhat.com>)> wrote: Hmm. The log says the server supports extensions, the detection of the client extension support went well too, the SSH_MSG_EXT_INFO packet is also sent, so it is not clear to me why it should not work. [2025/05/23 14:02:12.155371, 3] 10.10.10.133 - ssh_server_send_extensions: Sending SSH_MSG_EXT_INFO The server is also sending sha2 hostkey signature which is correctly verified by the client. Looking again at the client log, I see that the packet SSH_MSG_EXT_INFO is not being processed by the callbacks before you attempt to authenticate, which means the extension from this packet are not taken into the account. So this, from my understanding, sounds like a bug in the client, that it sends the authentication requests before fully processing the messages sent by the server. I think it might be possible to get over that by calling the ssh_userauth_none() first, which will get you the list of server supported authentication methods (and as a side effect, it should process all the outstanding messages, including the extension). Looking at the tutorial, I see this is not very well described. It mostly says, "don't use this" and next section shows its use without any explanation. https://api.libssh.org/master/libssh_tutor_authentication.html (https://api.libssh.org/master/libssh_tutor_authentication.html) This would be probably good to improve a bit. Please, let me know if the a above suggestion solves the problem for you. If so, I will try to update the tutorial to reflect this. Thanks for the patience! Jakub On Fri, May 23, 2025 at 2:17 PM <g4-l...@tonarchiv.ch (mailto:g4-l...@tonarchiv.ch)> wrote: Here you go (attached). Cheers Till May 23, 2025 9:50 AM, "Jakub Jelen" <jje...@redhat.com (mailto:jje...@redhat.com?to=%22jakub%20jelen%22%20%3cjje...@redhat.com%3E)> wrote: 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 (mailto: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 (mailto: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 (mailto: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 (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 (mailto: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
