Send server-sig-algs on handshake per RFC 8308

Problem to solve

It adds support for the server-sig-algs extension on server side. The supported algorithms are sent via SSH_MSG_EXT_INFO message. It's inspired by https://github.com/golang/crypto/pull/197/files, but takes only the part that allows a server to send server-sig-algs to a client; client-side and ability to provide custom extensions are omitted.

Now SSH2_MSG_EXT_INFO with specified list of algorithms is sent:

debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

Fixes: gitlab-shell#543 (closed)

RFC 8308: https://datatracker.ietf.org/doc/html/rfc8308

Q & A

1. https://datatracker.ietf.org/doc/html/rfc8308 3.1 says:

If a server does not send this extension, a client MUST NOT make any
assumptions about the server's public key algorithm support, and MAY
proceed with authentication requests using trial and error.  Note
that implementations are known to exist that apply authentication
penalties if the client attempts to use an unexpected public key
algorithm.

Is this exposing a client bug/shortcoming related to disabling SHA-1?

• Before 8.8 version, OpenSSH client tried and sent ssh-rsa public keys, even if a server didn't send the extension. But since 8.8, OpenSSH client doesn't do it by default. It requires either a client to specify -o PubkeyAcceptedAlgorithms=ssh-rsa option to preserve the previous behavior or a server to send the extension

2. If there is some CVE in this package before this upstream changes are merged, we're going to have to maintain this fork and possibly deal with conflicts. Are we okay with that?

• Yes, but it doesn't seem to be a huge overhead (in case we don't have complex conflicts). Gitlab Shell maintainers will be responsible for doing it.

3. Since https://github.com/golang/crypto/pull/197/files and https://go-review.googlesource.com/c/crypto/+/360195#message-899ce2286fdf8997922b71d87f86b47e62108822 seem to have be open since November without further comments/activity, is there anything we can do to help speed up this?

• According to https://github.com/golang/crypto/pull/197#issuecomment-978132412 this PR is discussed in Slack directly with the maintainers. Since the PR suggests changes to API (ability to customize the extensions), I understand why it may take some time. The plan is to focus on our own problem and move forward with gitlab-sshd deployment. Then we could share our findings or suggest merging a smaller iteration.

The fork is temporary

We're forking the package just to move forward with gitlab-sshd deployment. When the upstream code in ssh: add support for extension negotiation (rfc 8308) is merged, we can remove the fork and use the upstream instead.