[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#998619: openssh-server: server-sig-algs



On Thu, Nov 04, 2021 at 11:27:15PM -0300, Rafael Giangiulio wrote:
>    * What led up to the situation?
> 
> 	after changing all keys and keyex on sshd_config values so that sshd uses only "curve25519" algs, running "sshd -T" show everything allright but when connecting i get:
> 	debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>

There's already a comment in the upstream source code about this:

    static int
    kex_send_ext_info(struct ssh *ssh)
    {
            int r;
            char *algs;
    
            debug("Sending SSH2_MSG_EXT_INFO");
            if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL)
                    return SSH_ERR_ALLOC_FAIL;
            /* XXX filter algs list by allowed pubkey/hostbased types */
            if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 ||
                (r = sshpkt_put_u32(ssh, 1)) != 0 ||
                (r = sshpkt_put_cstring(ssh, "server-sig-algs")) != 0 ||
                (r = sshpkt_put_cstring(ssh, algs)) != 0 ||
                (r = sshpkt_send(ssh)) != 0) {
                    error_fr(r, "compose");
                    goto out;
            }
            /* success */
            r = 0;
     out:
            free(algs);
            return r;
    }

Does it cause a practical problem of any kind?  ssh-ed25519 is still
first in the server-sig-algs list so any client that supports both
ssh-ed25519 and the server-sig-algs extension mechanism will select it,
and attempts to send public key material signed using a different
algorithm will be rejected later anyway due to PubkeyAcceptedKeyTypes
(renamed to PubkeyAcceptedAlgorithms in OpenSSH 8.5).  So as far as I
can see this is essentially cosmetic.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]


Reply to: