On Tuesday, 20 May 2025 02:56:28 CEST g4-l...@tonarchiv.ch 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-l...@tonarchiv.ch (mailto:g4-l...@tonarchiv.ch) > 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-l...@tonarchiv.ch (mailto:g4-l...@tonarchiv.ch) > 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-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ecdsa-sha2-nistp384-cert- > v...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp256-cert- > v...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),rsa-sha2-512-cert-v01@ope > nssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com),rsa-sha2-256-cert-...@openssh.co > m > (mailto:rsa-sha2-256-cert-...@openssh.com),ecdsa-sha2-nistp521,ecdsa-sha2-n > istp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256 > ssh-ed25519-cert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com),ecdsa-sha2-nistp521-cert-v01@open > ssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ecdsa-sha2-nistp384-cert- > v...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp256-cert- > v...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),sk-ecdsa-sha2-nistp256-ce > rt-...@openssh.com > (mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com),rsa-sha2-512-cert-v01@ > openssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com),rsa-sha2-256-cert-...@openssh.co > m > (mailto:rsa-sha2-256-cert-...@openssh.com),ssh-ed25519,ecdsa-sha2-nistp521, > ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25...@openssh.com > (mailto:sk-ssh-ed25...@openssh.com),sk-ecdsa-sha2-nistp...@openssh.com > (mailto:sk-ecdsa-sha2-nistp...@openssh.com),rsa-sha2-512,rsa-sha2-256 > ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,sk- > ssh-ed25...@openssh.com > (mailto:sk-ssh-ed25...@openssh.com),sk-ecdsa-sha2-nistp...@openssh.com > (mailto:sk-ecdsa-sha2-nistp...@openssh.com),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-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com),sk-ssh-ed25519-cert-v01@openssh.c > om > (mailto:sk-ssh-ed25519-cert-...@openssh.com),ecdsa-sha2-nistp521-cert-v01@o > penssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ecdsa-sha2-nistp384-cert- > v...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp256-cert- > v...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),sk-ecdsa-sha2-nistp256-ce > rt-...@openssh.com > (mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com),rsa-sha2-512-cert-v01@ > openssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com),rsa-sha2-256-cert-...@openssh.co > m (mailto:rsa-sha2-256-cert-...@openssh.com),ssh-rsa-cert-...@openssh.com > (mailto:ssh-rsa-cert-...@openssh.com),ssh-ed25519,ecdsa-sha2-nistp521,ecdsa > -sha2-nistp384,ecdsa-sha2-nistp256,sk-ssh-ed25...@openssh.com > (mailto:sk-ssh-ed25...@openssh.com),sk-ecdsa-sha2-nistp...@openssh.com > (mailto:sk-ecdsa-sha2-nistp...@openssh.com),rsa-sha2-512,rsa-sha2-256,ssh-r > sa rsa-sha2-256-cert-...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com) > rsa-sha2-512-cert-...@openssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com) 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-...@openssh.com (mailto:ssh-rsa-cert-...@openssh.com) > > 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-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),ecdsa-sha2-nistp384,ecdsa > -sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp521,ecdsa > -sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ssh-ed25519,ssh-ed25519-c > ert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com),rsa-sha2-256,rsa-sha2-256-cert-v0 > 1...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com),rsa-sha2-512,rsa-sha2-512-cert-v > 0...@openssh.com (mailto:rsa-sha2-512-cert-...@openssh.com)> > ssh_key_algorithm_allowed: Checking rsa-sha2-256 with list > <ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),ecdsa-sha2-nistp384,ecdsa > -sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp521,ecdsa > -sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ssh-ed25519,ssh-ed25519-c > ert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com),rsa-sha2-256,rsa-sha2-256-cert-v0 > 1...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com),rsa-sha2-512,rsa-sha2-512-cert-v > 0...@openssh.com (mailto:rsa-sha2-512-cert-...@openssh.com)> > ssh_key_algorithm_allowed: Checking ssh-rsa with list > <ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),ecdsa-sha2-nistp384,ecdsa > -sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp521,ecdsa > -sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ssh-ed25519,ssh-ed25519-c > ert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com),rsa-sha2-256,rsa-sha2-256-cert-v0 > 1...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com),rsa-sha2-512,rsa-sha2-512-cert-v > 0...@openssh.com (mailto:rsa-sha2-512-cert-...@openssh.com)> > 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" <bouaksama...@gmail.com > (mailto:bouaksama...@gmail.com?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-l...@tonarchiv.ch > (mailto:g4-l...@tonarchiv.ch)> 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" <bouaksama...@gmail.com > (mailto:bouaksama...@gmail.com?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-l...@tonarchiv.ch > (mailto:g4-l...@tonarchiv.ch)> 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 a...@cryptomilk.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
