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

Hi Colin,
Thanks for ur time, it is indeed cosmetic, im just afraid this might lead to some sort of exploitation somehow... but for now not causing any practical problem.do you know any workaround to disable this extention?thanks in advance.
Rafael Giangiulio 
 
  Em sáb., 6 6e nov. 6e 2021 às 9:38, Colin Watson<[email protected]> escreveu:   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,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>

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)                              [[email protected]]