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-...@openssh.com
(mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp256-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),rsa-sha2-512-cert-...@openssh.com
(mailto:rsa-sha2-512-cert-...@openssh.com),rsa-sha2-256-cert-...@openssh.com
(mailto:rsa-sha2-256-cert-...@openssh.com),ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256
ssh-ed25519-cert-...@openssh.com
(mailto:ssh-ed25519-cert-...@openssh.com),ecdsa-sha2-nistp521-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ecdsa-sha2-nistp384-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp256-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),sk-ecdsa-sha2-nistp256-cert-...@openssh.com
(mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com),rsa-sha2-512-cert-...@openssh.com
(mailto:rsa-sha2-512-cert-...@openssh.com),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),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-rsa
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-...@openssh.com
(mailto:sk-ssh-ed25519-cert-...@openssh.com),ecdsa-sha2-nistp521-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp521-cert-...@openssh.com),ecdsa-sha2-nistp384-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp384-cert-...@openssh.com),ecdsa-sha2-nistp256-cert-...@openssh.com
(mailto:ecdsa-sha2-nistp256-cert-...@openssh.com),sk-ecdsa-sha2-nistp256-cert-...@openssh.com
(mailto:sk-ecdsa-sha2-nistp256-cert-...@openssh.com),rsa-sha2-512-cert-...@openssh.com
(mailto:rsa-sha2-512-cert-...@openssh.com),rsa-sha2-256-cert-...@openssh.com
(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-rsa
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-cert-...@openssh.com
(mailto:ssh-ed25519-cert-...@openssh.com),rsa-sha2-256,rsa-sha2-256-cert-...@openssh.com
(mailto:rsa-sha2-256-cert-...@openssh.com),rsa-sha2-512,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),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-cert-...@openssh.com
(mailto:ssh-ed25519-cert-...@openssh.com),rsa-sha2-256,rsa-sha2-256-cert-...@openssh.com
(mailto:rsa-sha2-256-cert-...@openssh.com),rsa-sha2-512,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),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-cert-...@openssh.com
(mailto:ssh-ed25519-cert-...@openssh.com),rsa-sha2-256,rsa-sha2-256-cert-...@openssh.com
(mailto:rsa-sha2-256-cert-...@openssh.com),rsa-sha2-512,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?to=%22Malak%20Bouaksa%22%20<bouaksama...@gmail.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%3cbouaksama...@gmail.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
