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
