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

[g4-lisz@xxxxxxxxxxxx]

Hi Andreas,

You saved my day (or night)!

$ sudo update-crypto-policies --set LEGACY
...
025/05/20 13:38:51.144356, 2] ssh_userauth_publickey_auto:  Successfully authenticated using /home/user/id_rsa
Connected and authenticated with key!

Cheers,
Till

May 20, 2025 9:28 AM, "Andreas Schneider" <asn@xxxxxxxxxxxxxx> wrote:

> On Tuesday, 20 May 2025 02:56:28 CEST g4-lisz@xxxxxxxxxxxx wrote:
> 
>> Sorry, I missed a few important lines:
> 
> My guess would be that the crypto policy is preventing the use of SHA-1 and
> you need to enable it. libssh has support for crypto policies with 0.10.
> 
> https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html
> security_hardening/using-the-system-wide-cryptographic-policies_security-
> hardening
> 
> https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html
> security_hardening/using-the-system-wide-cryptographic-policies_security-
> hardening#proc_re-enabling-sha-1_using-the-system-wide-cryptographic-policies
> 
>> int ssh_key_algorithm_allowed(ssh_session session, const char *type)
>> {
>> const char *allowed_list;
>> 
>> if (session->client) {
>> ===>> allowed_list = session->opts.pubkey_accepted_types; <<===
>> if (allowed_list == NULL) {
>> if (ssh_fips_mode()) {
>> allowed_list = ssh_kex_get_fips_methods(SSH_HOSTKEYS);
>> } else {
>> allowed_list = ssh_kex_get_default_methods(SSH_HOSTKEYS);
>> }
>> I.e. it only uses the defaults if session->opts.pubkey_accepted_types is
>> undefined.
>> 
>> Back to the beginning. Why doesn't it work? My guess is that Redhat changed
>> the list of supported methods...
>> 
>> May 20, 2025 2:44 AM, g4-lisz@xxxxxxxxxxxx (g4-lisz@xxxxxxxxxxxx)
>> wrote: I wonder if this is a bug...
>> 
>> I did some digging in the code (0.10.4).
>> 
>> The error message "The key algorithm 'ssh-rsa' is not allowed to be used by
>> PUBLICKEY_ACCEPTED_TYPES" comes from: ssh_userauth_try_publickey(). This
>> uses:
>> 
>> auth.c:531: rc = ssh_key_algorithm_allowed(session, sig_type_c);
>> 
>> But ssh_key_algorithm_allowed() checks again ssh_kex_get_default_methods()
>> 
>> pki.c:371: allowed_list = ssh_kex_get_default_methods(SSH_HOSTKEYS);
>> 
>> ssh_kex_get_default_methods() returns a constant list
>> DEFAULT_PUBLIC_KEY_ALGORITHMS from static const char *default_methods[]
>> (kex.c:242).
>> 
>> Therefore ssh_userauth_try_publickey() always returns SSH_AUTH_DENIED if the
>> algorithm is not in the DEFAULT list.
>> 
>> How does this make sense? It doesn't respect the additional algorithms added
>> through the SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES option.
>> 
>> rsa-ssh would actually be supported. It's in the list supported_methods[] in
>> kex.c:240. This is used for ssh_keep_known_algos() (kex.c:957) and allows
>> to set the option to the session (options.c):
>> 
>> case SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES:
>> v = value;
>> if (v == NULL || v[0] == '') {
>> ssh_set_error_invalid(session);
>> return -1;
>> } else {
>> if (ssh_fips_mode()) {
>> p = ssh_keep_fips_algos(SSH_HOSTKEYS, v);
>> } else {
>> p = ssh_keep_known_algos(SSH_HOSTKEYS, v);
>> }
>> if (p == NULL) {
>> ssh_set_error(session, SSH_REQUEST_DENIED,
>> "Setting method: no known public key algorithm (%s)",
>> v);
>> return -1;
>> }
>> 
>> SAFE_FREE(session->opts.pubkey_accepted_types);
>> session->opts.pubkey_accepted_types = p;
>> }
>> 
>> So what's the sense of allowing to add the algorithm through the option, but
>> then denying the key because it's algorithm is not in the default list?
>> IMHO SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES makes no sense this way...
>> 
>> Cheers
>> Till
>> 
>> May 20, 2025 1:48 AM, g4-lisz@xxxxxxxxxxxx (g4-lisz@xxxxxxxxxxxx)
>> wrote: Nice hint to use 'strings'. But from the output it's hard to tell.
>> There are a few appearances: rsa-sha2-512
>> rsa-sha2-512,rsa-sha2-256,ssh-rsa
>> ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp384-cert-
>> v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp256-cert-
>> v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),rsa-sha2-512-cert-v01@ope
>> nssh.com
>> (rsa-sha2-512-cert-v01@xxxxxxxxxxx),rsa-sha2-256-cert-v01@xxxxxxxxxx
>> m
>> (rsa-sha2-256-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp521,ecdsa-sha2-n
>> istp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256
>> ssh-ed25519-cert-v01@xxxxxxxxxxx
>> (ssh-ed25519-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp521-cert-v01@open
>> ssh.com
>> (ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp384-cert-
>> v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp256-cert-
>> v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),sk-ecdsa-sha2-nistp256-ce
>> rt-v01@xxxxxxxxxxx
>> (sk-ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),rsa-sha2-512-cert-v01@
>> openssh.com
>> (rsa-sha2-512-cert-v01@xxxxxxxxxxx),rsa-sha2-256-cert-v01@xxxxxxxxxx
>> m
>> (rsa-sha2-256-cert-v01@xxxxxxxxxxx),ssh-ed25519,ecdsa-sha2-nistp521,
>> ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25519@xxxxxxxxxxx
>> (sk-ssh-ed25519@xxxxxxxxxxx),sk-ecdsa-sha2-nistp256@xxxxxxxxxxx
>> (sk-ecdsa-sha2-nistp256@xxxxxxxxxxx),rsa-sha2-512,rsa-sha2-256
>> ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-
>> ssh-ed25519@xxxxxxxxxxx
>> (sk-ssh-ed25519@xxxxxxxxxxx),sk-ecdsa-sha2-nistp256@xxxxxxxxxxx
>> (sk-ecdsa-sha2-nistp256@xxxxxxxxxxx),rsa-sha2-512,rsa-sha2-256,ssh-r
>> sa The provided value (%u) for minimal RSA key size is too small. Use at
>> least 768 bits. Either RSA or DSS must be chosen
>> ssh-ed25519-cert-v01@xxxxxxxxxxx
>> (ssh-ed25519-cert-v01@xxxxxxxxxxx),sk-ssh-ed25519-cert-v01@openssh.c
>> om
>> (sk-ssh-ed25519-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp521-cert-v01@o
>> penssh.com
>> (ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp384-cert-
>> v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp256-cert-
>> v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),sk-ecdsa-sha2-nistp256-ce
>> rt-v01@xxxxxxxxxxx
>> (sk-ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),rsa-sha2-512-cert-v01@
>> openssh.com
>> (rsa-sha2-512-cert-v01@xxxxxxxxxxx),rsa-sha2-256-cert-v01@xxxxxxxxxx
>> m (rsa-sha2-256-cert-v01@xxxxxxxxxxx),ssh-rsa-cert-v01@xxxxxxxxxxx
>> (ssh-rsa-cert-v01@xxxxxxxxxxx),ssh-ed25519,ecdsa-sha2-nistp521,ecdsa
>> -sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25519@xxxxxxxxxxx
>> (sk-ssh-ed25519@xxxxxxxxxxx),sk-ecdsa-sha2-nistp256@xxxxxxxxxxx
>> (sk-ecdsa-sha2-nistp256@xxxxxxxxxxx),rsa-sha2-512,rsa-sha2-256,ssh-r
>> sa rsa-sha2-256-cert-v01@xxxxxxxxxxx
>> (rsa-sha2-256-cert-v01@xxxxxxxxxxx)
>> rsa-sha2-512-cert-v01@xxxxxxxxxxx
>> (rsa-sha2-512-cert-v01@xxxxxxxxxxx) Failed to build RSA public key
>> The '%s' key of size %d is not allowd by RSA_MIN_SIZE
>> Failed to build RSA private key
>> ssh-rsa
>> ssh-rsa-cert-v01@xxxxxxxxxxx (ssh-rsa-cert-v01@xxxxxxxxxxx)
>> 
>> I'm using a minimalistic code now for testing. But still the same result:
>> 
>> int main() {
>> ssh_session session;
>> int rc;
>> const char *hostname = "10.10.10.10";
>> const char *username = "user";
>> const char *keyfile = "/home/user/id_rsa";
>> int port = 22;
>> 
>> session = ssh_new();
>> if (session == NULL) {
>> fprintf(stderr, "Failed to create SSH sessionn");
>> return 1;
>> }
>> 
>> ssh_set_log_level(SSH_LOG_FUNCTIONS);
>> ssh_options_set(session, SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES, "+ssh-rsa");
>> ssh_options_set(session, SSH_OPTIONS_HOST, hostname);
>> ssh_options_set(session, SSH_OPTIONS_PORT, &port);
>> ssh_options_set(session, SSH_OPTIONS_USER, username);
>> ssh_options_set(session, SSH_OPTIONS_IDENTITY, keyfile);
>> 
>> rc = ssh_connect(session);
>> if (rc != SSH_OK) {
>> fprintf(stderr, "Error connecting to %s: %sn", hostname,
>> ssh_get_error(session)); ssh_free(session);
>> return 1;
>> }
>> 
>> rc = ssh_userauth_publickey_auto(session, NULL, NULL);
>> if (rc != SSH_AUTH_SUCCESS) {
>> fprintf(stderr, "Authentication failed: %sn", ssh_get_error(session));
>> ssh_disconnect(session);
>> ssh_free(session);
>> return 1;
>> }
>> 
>> printf("Connected and authenticated with key!n");
>> 
>> ssh_disconnect(session);
>> ssh_free(session);
>> return 0;
>> }
>> 
>> Output:
>> ssh_userauth_publickey_auto: Trying to authenticate with
>> /home/remadmin/id_rsa ssh_key_algorithm_allowed: Checking rsa-sha2-512 with
>> list <ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp384,ecdsa
>> -sha2-nistp384-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp521,ecdsa
>> -sha2-nistp521-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx),ssh-ed25519,ssh-ed25519-c
>> ert-v01@xxxxxxxxxxx
>> (ssh-ed25519-cert-v01@xxxxxxxxxxx),rsa-sha2-256,rsa-sha2-256-cert-v0
>> 1@xxxxxxxxxxx
>> (rsa-sha2-256-cert-v01@xxxxxxxxxxx),rsa-sha2-512,rsa-sha2-512-cert-v
>> 01@xxxxxxxxxxx (rsa-sha2-512-cert-v01@xxxxxxxxxxx)>
>> ssh_key_algorithm_allowed: Checking rsa-sha2-256 with list
>> <ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp384,ecdsa
>> -sha2-nistp384-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp521,ecdsa
>> -sha2-nistp521-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx),ssh-ed25519,ssh-ed25519-c
>> ert-v01@xxxxxxxxxxx
>> (ssh-ed25519-cert-v01@xxxxxxxxxxx),rsa-sha2-256,rsa-sha2-256-cert-v0
>> 1@xxxxxxxxxxx
>> (rsa-sha2-256-cert-v01@xxxxxxxxxxx),rsa-sha2-512,rsa-sha2-512-cert-v
>> 01@xxxxxxxxxxx (rsa-sha2-512-cert-v01@xxxxxxxxxxx)>
>> ssh_key_algorithm_allowed: Checking ssh-rsa with list
>> <ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp384,ecdsa
>> -sha2-nistp384-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx),ecdsa-sha2-nistp521,ecdsa
>> -sha2-nistp521-cert-v01@xxxxxxxxxxx
>> (ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx),ssh-ed25519,ssh-ed25519-c
>> ert-v01@xxxxxxxxxxx
>> (ssh-ed25519-cert-v01@xxxxxxxxxxx),rsa-sha2-256,rsa-sha2-256-cert-v0
>> 1@xxxxxxxxxxx
>> (rsa-sha2-256-cert-v01@xxxxxxxxxxx),rsa-sha2-512,rsa-sha2-512-cert-v
>> 01@xxxxxxxxxxx (rsa-sha2-512-cert-v01@xxxxxxxxxxx)>
>> ssh_userauth_try_publickey: The key algorithm 'ssh-rsa' is not allowed to
>> be used by PUBLICKEY_ACCEPTED_TYPES configuration option
>> ssh_userauth_publickey_auto: Public key for /home/remadmin/id_rsa refused
>> by server
>> 
>> To your last question: I'm simply talking to the libssh mailing list! My
>> name is Till.
>> 
>> Cheers
>> 
>> May 19, 2025 11:59 PM, "Malak Bouaksa" <bouaksamalak@xxxxxxxxx
>> (bouaksamalak@xxxxxxxxx?to=%22Malak%20Bouaksa%22%20<bouaksamalak@gma
>> il.com>)> wrote: You're absolutely right to be confused — that error message
>> is really misleading. When libssh says the key was “refused by server,” it
>> often doesn’t actually mean the server rejected it. In your case, the
>> message "The key algorithm 'ssh-rsa' is not allowed to be used by
>> PUBLICKEY_ACCEPTED_TYPES configuration option" shows that it’s the client
>> itself, not the server, refusing the key. It’s likely that libssh 0.10.4 is
>> filtering out ssh-rsa internally before it even tries to use it. This is a
>> new default behavior introduced for security reasons, since ssh-rsa uses
>> SHA-1, which is considered weak. To allow it, make sure you're calling
>> ssh_options_set(session, SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES, "+ssh-rsa")
>> (without a space after the plus) before calling ssh_connect(). If you set
>> it too late, the option won’t take effect. Also consider setting
>> SSH_OPTIONS_HOSTKEYS to include +ssh-rsa, just in case host key filtering
>> is also in play. Finally, it’s worth checking whether your system’s libssh
>> was compiled with ssh-rsa support disabled entirely — some distros remove
>> it completely. A quick way to test that is by running strings on the libssh
>> shared library to see if ssh-rsa appears at all. So no, the server probably
>> isn’t refusing the key — your client just won’t let it be used unless you
>> configure it properly, and sometimes not even then if it’s compiled out.
>> 
>> And can I know who is talking to me and how you got my email?
>> 
>> Thank you and I hope I helped with your problem.
>> On Mon, May 19, 2025 at 10:14 PM <g4-lisz@xxxxxxxxxxxx
>> (g4-lisz@xxxxxxxxxxxx)> wrote: Hi there and thanks for your reply!
>> 
>> You mean ' ssh-rsa' i.e. without any space? I also tried that, and with a
>> complete list, too: sh_options_set(session,
>> SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES,
>> "rsa-sha2-256,rsa-sha2-512,ecdh-sha2-nistp256,ssh-rsa"
>> 
>> Nothing seems to help so far...
>> 
>> It actually says (with debug log level);
>> ssh_userauth_publickey_auto: ssh_userauth_publickey_auto: Public key for
>> /opt/myproxy/.ssh/id_rsa refused by server ssh_userauth_publickey_auto:
>> Access denied: Tried every public key, none matched
>> ssh_userauth_publickey_auto Instance #11 failed: The key algorithm
>> 'ssh-rsa' is not allowed to be used by PUBLICKEY_ACCEPTED_TYPES
>> configuration option
>> 
>> The last line comes from ssh_get_error(session):
>> if(ssh_userauth_publickey_auto(session, NULL, NULL) != SSH_AUTH_SUCCESS) {
>> tlog_error("ssh_userauth_password Instance #%d failed: %s",
>> inst->instance_id, ssh_get_error(session)); ...
>> But why it says: refused by server? Is this just a bad wording? Or is it
>> really rejected by the peer?
>> 
>> May 19, 2025 10:19 PM, "Malak Bouaksa" <bouaksamalak@xxxxxxxxx
>> (bouaksamalak@xxxxxxxxx?to=%22Malak%20Bouaksa%22%20%3Cbouaksamalak@g
>> mail.com%3E)> wrote: Hey there,
>> 
>> What you're running into is actually a common issue when jumping from
>> libssh 0.9.x to 0.10.x. Starting with version 0.10, libssh made a
>> security-related change: it no longer allows the 'ssh-rsa' key type by
>> default because it's based on SHA-1, which is considered weak by modern
>> cryptographic standards. That’s why everything worked fine with version
>> 0.9.6, but with 0.10.4 on RHEL9
>> 
>> That’s why everything worked fine with version 0.9.6, but with 0.10.4
> 
> on
> 
>> RHEL9 but here’s the catch: the space after the + is messing it up. It
>> should be: ssh_options_set(session, SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES,
>> "+ ssh-rsa"); On Mon, May 19, 2025 at 8:58 PM <g4-lisz@xxxxxxxxxxxx
>> (g4-lisz@xxxxxxxxxxxx)> wrote: Hi there,
>> 
>> I wrote a client (TCP forwarding) that connects to a server which uses
>> libssh V 0.9.7.
>> 
>> When I compile the client with 0.9.6 (this is what I get with libssh-dev on
>> Pop!_OS 22.04) then all works fine.
>> 
>> However, on RHEL9, libssh-dev brings v0.10.4. And compiled with that version
>> the client can't connect anymore:
>> 
>> "ssh_userauth_try_publickey: The key algorithm 'ssh-rsa' is not allowed to
>> be used by PUBLICKEY_ACCEPTED_TYPES configuration option"
>> 
>> At first I was confused: Who says this? The server? But it accepted the key
>> when using a client with version 0.9.6. So I tried to add 'ssh-rsa' to the
>> client's allowed key types:
>> 
>> if (ssh_options_set(session, SSH_OPTIONS_PUBLICKEY_ACCEPTED_TYPES, "+
>> ssh-rsa") < 0) { fprintf(stderr, "ssh_options_set failed: %sn",
>> ssh_get_error(session); }
>> 
>> ssh_options_set(...) seems to succeed. However, everything else remains the
>> same. The key algorithm 'ssh-rsa' is not allowed to be used...
>> 
>> How can this be solved? What is the right way to convince libssh that it can
>> use public keys of type ssh-rsa?
>> 
>> The remote account only knows my ssh-rsa public key and this can't be
>> changed easily. That's why I have to stick with that type...
>> 
>> Cheers
>> Till
> 
> --
> Andreas Schneider asn@xxxxxxxxxxxxxx
> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D