search for: sshkey_ssh_name

...KEY_RSA && key->type != KEY_RSA_CERT)) { + (key->type != KEY_RSA && key->type != KEY_RSA_CERT) || + (key->type == KEY_RSA_CERT && (datafellows & SSH_BUG_SIGTYPE))) { /* Filter base key signature alg against our configuration */ return match_list(sshkey_ssh_name(key), options.pubkey_key_types, NULL);

...2100 if (sshkey_equal(l->key, ctx->keys[i])) { > 2101 ctx->other_name_seen = 1; > 2102 debug3_f("found %s key under different " > 2103 "name/addr at %s:%ld", > 2104 sshkey_ssh_name(ctx->keys[i]), > 2105 l->path, l->linenum); > 2106 return 0; > 2107 } > 2108 } Thank you! Increasing the verbosity revealed a known_hosts entry linked to serverA's IP address (I had forgotten that I had connected to i...

...t it matches too: 2100 if (sshkey_equal(l->key, ctx->keys[i])) { 2101 ctx->other_name_seen = 1; 2102 debug3_f("found %s key under different " 2103 "name/addr at %s:%ld", 2104 sshkey_ssh_name(ctx->keys[i]), 2105 l->path, l->linenum); 2106 return 0; 2107 } 2108 } -d

...->type != KEY_RSA && key->type != KEY_RSA_CERT) || > > + (key->type == KEY_RSA_CERT && (datafellows & SSH_BUG_SIGTYPE))) { > > /* Filter base key signature alg against our configuration */ > > return match_list(sshkey_ssh_name(key), > > options.pubkey_key_types, NULL); > > That fixes it for me, thank you. Would you still like a copy of the > previous failing client trace? No, I think I figured it out :)

From: Maxime Rey <maximejeanrey at gmail.com> Hello, I've discovered an issue with sshd when it's configured to use the SSH agent alongside multiple host keys. Specifically, this problem happens during the hostkeys-prove-00 at openssh.com request, when the server attempts to demonstrate ownership of the host keys by calling the agent. The issue occurs because, while processing the

Hi, I created new host keys on serverA, updated sshd_config accordingly (adding the line below) and restarted ssh: cd /etc/ssh sudo ssh-keygen -f 2024_ssh_host_ed25519_key -t ed25519 -N '' sudo vi /etc/ssh/sshd_config # added line: HostKey /etc/ssh/2024_ssh_host_ed25519_key sudo service ssh restart When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) afterwards,

...shkey_equal(l->key, ctx->keys[i])) { > > 2101 ctx->other_name_seen = 1; > > 2102 debug3_f("found %s key under different " > > 2103 "name/addr at %s:%ld", > > 2104 sshkey_ssh_name(ctx->keys[i]), > > 2105 l->path, l->linenum); > > 2106 return 0; > > 2107 } > > 2108 } > > Thank you! Increasing the verbosity revealed a known_hosts entry linked > to serverA's IP address (I had f...

On Thu, Oct 11, 2018 at 10:41 AM Damien Miller <djm at mindrot.org> wrote: > On Wed, 10 Oct 2018, Adam Eijdenberg wrote: > > We see this error on the client side: > > > > debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> > > ... > > debug1: Offering public key: RSA-CERT SHA256:xxx /path/to/key > > debug1: send_pubkey_test: no

...eady been checked against the local security policy before key_sig_algorithm is called, so key_sig_algorithm shouldn't be acting as a filter. It should be finding the correct name to refer to the client's key type. I'd suggest dropping the call to match_list, and instead simply return sshkey_ssh_name(key) for all non-RSA key types, and for RSA key types when connecting to a legacy server with SSH_BUG_SIGTYPE set. -- You are receiving this mail because: You are watching the assignee of the bug.

...entry=0) at match.c:156 #2 0x000055555556447c in list_hostkey_types () at sshd.c:794 #3 do_ssh2_kex () at sshd.c:2327 #4 0x00005555555622c1 in main (ac=<optimized out>, av=<optimized out>) at sshd.c:2181 Problem is in list_hostkey_types() which is not checking the return value of sshkey_ssh_name() (for RSA1 returns NULL). The openssh is build --with-ssh1 (to support SSH1 in clients), but that should not matter. I am not sure about the plans what everything will be removed in next release and if if maters for future, but certainly it maters for us that it is crashing sshd at this moment....

Hi, I'm doing some test with a pkcs11 token that can only sign short messages. When connecting to one server, that reports pkalg rsa-sha2-512 blen 151, it fails to sign the pubkey because it is 83 bytes long. (sshd: OpenSSH_7.3p1) A older server that reports pkalg ssh-rsa blen 151, works perfectly as the pubkey signature required is only 35 bytes long. (sshd: OpenSSH_6.7p1) I am not sure

https://bugzilla.mindrot.org/show_bug.cgi?id=2746 Bug ID: 2746 Summary: RFE: Allow to disable SHA1 signatures for RSA Product: Portable OpenSSH Version: 7.5p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

...p; kt->sigonly) continue; if ((certs_only && !kt->cert) || (plain_only && kt->cert)) continue; diff --git a/sshkey.h b/sshkey.h index f393638..6a3ff2f 100644 --- a/sshkey.h +++ b/sshkey.h @@ -156,7 +156,7 @@ int sshkey_ec_validate_private(const EC_KEY *); const char *sshkey_ssh_name(const struct sshkey *); const char *sshkey_ssh_name_plain(const struct sshkey *); int sshkey_names_valid2(const char *, int); -char *sshkey_alg_list(int, int, char); +char *sshkey_alg_list(int, int, int, char); int sshkey_from_blob(const u_char *, size_t, struct sshkey **); int sshkey_fromb(st...