Hi Jakub, the server is built on libssh V 0.9.7 on Windows using MinGW. What would it mean when it supports SHA2 RSA? Would this be used as "upgraded" algorithm for ssh-rsa?
BTW Connecting to the server from RHEL with openssh client worked also with crypto policy set do DEFAULT... Cheers Till May 20, 2025 10:34 AM, "Jakub Jelen" <jje...@redhat.com (mailto:jje...@redhat.com?to=%22Jakub%20Jelen%22%20<jje...@redhat.com>)> wrote: 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 (mailto:a...@cryptomilk.org)> wrote: On Tuesday, 20 May 2025 02:56:28 CEST g4-l...@tonarchiv.ch (mailto: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) > (mailto: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) > (mailto: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) > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com)),ecdsa-sha2-nistp384-cert- > v...@openssh.com (mailto:v...@openssh.com) > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com)),ecdsa-sha2-nistp256-cert- > v...@openssh.com (mailto:v...@openssh.com) > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com)),rsa-sha2-512-cert-v01@ope > nssh.com (http://nssh.com) > (mailto:rsa-sha2-512-cert-...@openssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com)),rsa-sha2-256-cert-...@openssh.co > (mailto:rsa-sha2-256-cert-...@openssh.co) > m > (mailto:rsa-sha2-256-cert-...@openssh.com > (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) > (mailto:ssh-ed25519-cert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com)),ecdsa-sha2-nistp521-cert-v01@open > ssh.com (http://ssh.com) > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com)),ecdsa-sha2-nistp384-cert- > v...@openssh.com (mailto:v...@openssh.com) > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com)),ecdsa-sha2-nistp256-cert- > v...@openssh.com (mailto:v...@openssh.com) > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com)),sk-ecdsa-sha2-nistp256-ce > rt-...@openssh.com (mailto:rt-...@openssh.com) > (mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com)),rsa-sha2-512-cert-v01@ > openssh.com (http://openssh.com) > (mailto:rsa-sha2-512-cert-...@openssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com)),rsa-sha2-256-cert-...@openssh.co > (mailto:rsa-sha2-256-cert-...@openssh.co) > m > (mailto:rsa-sha2-256-cert-...@openssh.com > (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) > (mailto:sk-ssh-ed25...@openssh.com > (mailto:sk-ssh-ed25...@openssh.com)),sk-ecdsa-sha2-nistp...@openssh.com > (mailto:sk-ecdsa-sha2-nistp...@openssh.com) > (mailto: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:ssh-ed25...@openssh.com) > (mailto:sk-ssh-ed25...@openssh.com > (mailto:sk-ssh-ed25...@openssh.com)),sk-ecdsa-sha2-nistp...@openssh.com > (mailto:sk-ecdsa-sha2-nistp...@openssh.com) > (mailto: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) > (mailto: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 > (mailto:sk-ssh-ed25519-cert-...@openssh.com)),ecdsa-sha2-nistp521-cert-v01@o > penssh.com (http://penssh.com) > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com)),ecdsa-sha2-nistp384-cert- > v...@openssh.com (mailto:v...@openssh.com) > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com)),ecdsa-sha2-nistp256-cert- > v...@openssh.com (mailto:v...@openssh.com) > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com)),sk-ecdsa-sha2-nistp256-ce > rt-...@openssh.com (mailto:rt-...@openssh.com) > (mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com)),rsa-sha2-512-cert-v01@ > openssh.com (http://openssh.com) > (mailto:rsa-sha2-512-cert-...@openssh.com > (mailto:rsa-sha2-512-cert-...@openssh.com)),rsa-sha2-256-cert-...@openssh.co > (mailto:rsa-sha2-256-cert-...@openssh.co) > m (mailto:rsa-sha2-256-cert-...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com)),ssh-rsa-cert-...@openssh.com > (mailto:ssh-rsa-cert-...@openssh.com) > (mailto: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) > (mailto:sk-ssh-ed25...@openssh.com > (mailto:sk-ssh-ed25...@openssh.com)),sk-ecdsa-sha2-nistp...@openssh.com > (mailto:sk-ecdsa-sha2-nistp...@openssh.com) > (mailto: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) > (mailto: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) > (mailto: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) > (mailto: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) > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com)),ecdsa-sha2-nistp384,ecdsa > -sha2-nistp384-cert-...@openssh.com > (mailto:sha2-nistp384-cert-...@openssh.com) > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com)),ecdsa-sha2-nistp521,ecdsa > -sha2-nistp521-cert-...@openssh.com > (mailto:sha2-nistp521-cert-...@openssh.com) > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com)),ssh-ed25519,ssh-ed25519-c > ert-...@openssh.com (mailto:ert-...@openssh.com) > (mailto:ssh-ed25519-cert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com)),rsa-sha2-256,rsa-sha2-256-cert-v0 > 1...@openssh.com (mailto:1...@openssh.com) > (mailto:rsa-sha2-256-cert-...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com)),rsa-sha2-512,rsa-sha2-512-cert-v > 0...@openssh.com (mailto:0...@openssh.com) > (mailto:rsa-sha2-512-cert-...@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) > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com)),ecdsa-sha2-nistp384,ecdsa > -sha2-nistp384-cert-...@openssh.com > (mailto:sha2-nistp384-cert-...@openssh.com) > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com)),ecdsa-sha2-nistp521,ecdsa > -sha2-nistp521-cert-...@openssh.com > (mailto:sha2-nistp521-cert-...@openssh.com) > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com)),ssh-ed25519,ssh-ed25519-c > ert-...@openssh.com (mailto:ert-...@openssh.com) > (mailto:ssh-ed25519-cert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com)),rsa-sha2-256,rsa-sha2-256-cert-v0 > 1...@openssh.com (mailto:1...@openssh.com) > (mailto:rsa-sha2-256-cert-...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com)),rsa-sha2-512,rsa-sha2-512-cert-v > 0...@openssh.com (mailto:0...@openssh.com) > (mailto:rsa-sha2-512-cert-...@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) > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp256-cert-...@openssh.com)),ecdsa-sha2-nistp384,ecdsa > -sha2-nistp384-cert-...@openssh.com > (mailto:sha2-nistp384-cert-...@openssh.com) > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp384-cert-...@openssh.com)),ecdsa-sha2-nistp521,ecdsa > -sha2-nistp521-cert-...@openssh.com > (mailto:sha2-nistp521-cert-...@openssh.com) > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com > (mailto:ecdsa-sha2-nistp521-cert-...@openssh.com)),ssh-ed25519,ssh-ed25519-c > ert-...@openssh.com (mailto:ert-...@openssh.com) > (mailto:ssh-ed25519-cert-...@openssh.com > (mailto:ssh-ed25519-cert-...@openssh.com)),rsa-sha2-256,rsa-sha2-256-cert-v0 > 1...@openssh.com (mailto:1...@openssh.com) > (mailto:rsa-sha2-256-cert-...@openssh.com > (mailto:rsa-sha2-256-cert-...@openssh.com)),rsa-sha2-512,rsa-sha2-512-cert-v > 0...@openssh.com (mailto:0...@openssh.com) > (mailto:rsa-sha2-512-cert-...@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) > (mailto:bouaksama...@gmail.com > (mailto:bouaksama...@gmail.com)?to=%22Malak%20Bouaksa%22%20<bouaksamalak@gma > il.com (http://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) > (mailto: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) > (mailto:bouaksama...@gmail.com > (mailto:bouaksama...@gmail.com)?to=%22Malak%20Bouaksa%22%20%3Cbouaksamalak@g > mail.com (http://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) > (mailto: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 (mailto:a...@cryptomilk.org) GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
