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

[Jakub Jelen <jjelen@xxxxxxxxxx>]

Thanks for help debugging this, verification of the fix and for your
patience :)

We will get the change merged (once reviewed) and hopefully backported to
the older releases.

Jakub

On Fri, May 30, 2025 at 9:01 PM <g4-lisz@xxxxxxxxxxxx> wrote:

> Hi Jakub,
>
> I see, thanks for the explanation.
>
> I tested your merge request on RHEL 9 and the authentication succeeded
> without the use of SSH_OPTIONS_PROCESS_CONFIG = false or
> ssh_userauth_none().
> The log is attached.
> I also tested without the line:
> ssh_options_set(session, SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES,
> "ssh-rsa,rsa-sha2-256,rsa-sha2-512")
>
> This also successfully chooses rsa-sha2-512.
>
> Cheers,
> Till
>
> May 30, 2025 10:03 AM, "Jakub Jelen" <jjelen@xxxxxxxxxx
> <jjelen@xxxxxxxxxx?to=%22Jakub%20Jelen%22%20%3Cjjelen@xxxxxxxxxx%3E>>
> wrote:
>
> The RFC 8308 (extension negotiation) was added only recently on top of the
> existing RFCs and which libssh was built around.
> You are right that the `ssh_connect()` should make sure it processes the
> possible extensions or the authentication functions should process
> outstanding packets if there are any. But the way how the specs are written
> does not say that the message needs to come (it just MAY come):
> > A party that received the "ext-info-c" or "ext-info-s" indicator MAY
> send the following message
> https://datatracker.ietf.org/doc/html/rfc8308#section-2.3
> OTOH the SSH sends service request before authentication requests, which
> means that it should process outstanding messages. The problem is that this
> is done only after the key is being checked for compatibility right now,
> which is wrong. So this should be fixed. Can you try the following changes
> that they solve the problem (without the need for the none auth method?):
> https://gitlab.com/libssh/libssh-mirror/-/merge_requests/619
> Thanks,
> Jakub
> On Thu, May 29, 2025 at 9:53 PM <g4-lisz@xxxxxxxxxxxx> wrote:
>
> 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" <jjelen@xxxxxxxxxx
> <jjelen@xxxxxxxxxx?to=%22Jakub%20Jelen%22%20%3Cjjelen@xxxxxxxxxx%3E>>
> 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
> 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-lisz@xxxxxxxxxxxx> wrote:
>
> Here you go (attached).
>
> Cheers
> Till
>
> May 23, 2025 9:50 AM, "Jakub Jelen" <jjelen@xxxxxxxxxx
> <jjelen@xxxxxxxxxx?to=%22Jakub%20Jelen%22%20%3Cjjelen@xxxxxxxxxx%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-lisz@xxxxxxxxxxxx> wrote:
>
> On 5/22/25 12:38, Jakub Jelen wrote:
>
> 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 ...
>
> 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-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.
>
> 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
>
>
>
>
>