Hi. what is the SSH running on the server? Does it support for the SHA2 RSA (rfc8332)? If not, you need to go with the suggestion mentioned by Andreas -- changing the crypto policies to LEGACY or enabling SHA1 in signatures globally.
If the SSH server supports the RFC 8332, then everything should work (unless you force the use of SHA1 signatures somewhere in your code). Showing the debug log from the connection can give more hints. Jakub On Tue, May 20, 2025 at 9:37 AM Andreas Schneider <a...@cryptomilk.org> wrote: > 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- > <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 > <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 > > > >
