Re: The key algorithm 'ssh-rsa' is not allowed in V 0.10.4

[Jakub Jelen <jjelen@xxxxxxxxxx>]

On Wed, May 21, 2025 at 4:26 PM <g4-lisz@xxxxxxxxxxxx> wrote:

> On 5/21/25 15:53, Jakub Jelen wrote:
>
>
> On Wed, May 21, 2025 at 1:43 PM <g4-lisz@xxxxxxxxxxxx> 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 ...


> 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-sha256@xxxxxxxxxx,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.

Jakub