Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * 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>

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

	sshd_config:
kexalgorithms curve25519-sha256
hostbasedacceptedkeytypes ssh-ed25519
hostkeyalgorithms ssh-ed25519
pubkeyacceptedkeytypes ssh-ed25519
ciphers chacha20-poly1305@openssh.com
HostKey /etc/ssh/ssh_host_ed25519_key
casignaturealgorithms ssh-ed25519
macs hmac-sha2-512-etm@openssh.com
gssapikexalgorithms gss-curve25519-sha256-
Port 22
AddressFamily inet
SyslogFacility AUTHPRIV
LogLevel INFO
LoginGraceTime 15s
PermitRootLogin yes
StrictModes yes
MaxAuthTries 2
MaxSessions 5
ubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
AuthorizedPrincipalsFile none
AuthorizedKeysCommand none
AuthorizedKeysCommandUser nobody
HostbasedAuthentication no
IgnoreUserKnownHosts yes
IgnoreRhosts yes
UsePAM yes
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitTTY yes
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
Compression delayed
Subsystem       sftp    /usr/libexec/openssh/sftp-server

	output of "sshd -T":
port 22
addressfamily inet
listenaddress 0.0.0.0:22
usepam yes
logingracetime 15
x11displayoffset 10
maxauthtries 2
maxsessions 5
clientaliveinterval 0
clientalivecountmax 3
streamlocalbindmask 0177
permitrootlogin yes
ignorerhosts yes
ignoreuserknownhosts yes
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
pubkeyauthentication yes
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
gssapiauthentication no
gssapicleanupcredentials yes
gssapikeyexchange no
gssapistrictacceptorcheck yes
gssapistorecredentialsonrekey no
gssapikexalgorithms gss-curve25519-sha256-
passwordauthentication no
kbdinteractiveauthentication no
challengeresponseauthentication no
printmotd no
printlastlog yes
x11forwarding no
x11uselocalhost yes
permittty yes
permituserrc yes
strictmodes yes
tcpkeepalive yes
permitemptypasswords no
compression yes
gatewayports no
usedns no
allowtcpforwarding no
allowagentforwarding no
disableforwarding no
allowstreamlocalforwarding yes
streamlocalbindunlink no
fingerprinthash SHA256
exposeauthinfo no
pidfile /run/sshd.pid
xauthlocation /usr/bin/xauth
ciphers chacha20-poly1305@openssh.com
macs hmac-sha2-512-etm@openssh.com
banner none
forcecommand none
chrootdirectory none
trustedusercakeys none
revokedkeys none
securitykeyprovider internal
authorizedprincipalsfile none
versionaddendum none
authorizedkeyscommand none
authorizedkeyscommanduser nobody
authorizedprincipalscommand none
authorizedprincipalscommanduser none
hostkeyagent none
kexalgorithms curve25519-sha256
casignaturealgorithms ssh-ed25519
hostbasedacceptedkeytypes ssh-ed25519
hostkeyalgorithms ssh-ed25519
pubkeyacceptedkeytypes ssh-ed25519
loglevel INFO
syslogfacility AUTHPRIV
authorizedkeysfile .ssh/authorized_keys
hostkey /etc/ssh/ssh_host_ed25519_key
authenticationmethods any
subsystem sftp /usr/libexec/openssh/sftp-server
maxstartups 10:30:100
permittunnel no
ipqos lowdelay throughput
rekeylimit 0 0
permitopen any
permitlisten any
permituserenvironment no
pubkeyauthoptions none

   * What was the outcome of this action?

	yet cant get "server-sig-algs" to ssh-ed25519 only.

   * What outcome did you expect instead?

	server-sig-algs server offers changed from:
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>
	to:
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519>

*** End of the template - remove these template lines ***

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.

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<cjwatson@debian.org> escreveu:   On Thu, Nov 04, 2021 at 11:27:15PM -0300, Rafael Giangiulio wrote:

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.